lynx-check-css-support

Check Lynx CSS Support

Use the bundled CLI instead of inferring Lynx support from browser CSS behavior, documentation examples, or TypeScript types. Its data is pinned and bundled when the skill is built, so running a query never downloads or executes packages.

Treat this skill as the authority for declared backend/version availability. For questions about how a property behaves, layout semantics, syntax, or usage examples, consult the official Lynx documentation. If a request asks both whether a feature is supported and how it behaves, query support here first, then consult the docs.

Query support

Resolve this skill directory, then run:

node <skill-directory>/scripts/query-css-compat.mjs <property> [options]

Query the property's base compatibility across every backend:

node <skill-directory>/scripts/query-css-compat.mjs display

Pass the user's backend and Lynx version when provided. Omitting --backend returns every backend. --lynx-version classifies availability for that target; it does not change the published version_added value.

node <skill-directory>/scripts/query-css-compat.mjs display \
  --feature grid \
  --backend android \
  --lynx-version 2.0

Pass nested feature keys exactly as published. They are case-sensitive and may contain punctuation, such as Flex, rotateX, or circle(). If the exact key is unknown, inspect the property's compat_data with --json before querying the feature.

node <skill-directory>/scripts/query-css-compat.mjs filter \
  --feature brightness \
  --backend harmony \
  --lynx-version 3.5 \
  --json

Report findings

Give a concise answer containing:

• The property and nested feature/value, if any.
• The requested backend and Lynx version, or that all backends were compared.
• The resulting availability and published version_added value or condition.
• Any relevant notes, partial_implementation, deprecated, or experimental status.
• The @lynx-js/css-defines version shown by the script.

If a definition has no compat_data, report that compatibility is unspecified by the dataset. Do not interpret missing compatibility data as unsupported.

Never claim backend support from the definition's top-level version or a value's version field when compat_data.__compat.support provides backend-specific evidence. Do not treat declared availability as proof of browser parity or complete runtime behavior.

Interpret results

Treat version_added as follows:

• A numeric version string is the minimum Lynx version for that backend.
• A non-numeric string is a conditional requirement such as a targetSdkVersion gate; preserve and report it verbatim.
• true means supported without a numeric minimum in the dataset.
• false means unsupported.
• null means unknown.

Treat availability as follows:

• available: supported at the requested version, or supported at some version when no target was supplied.
• requires-newer-version: supported only after the requested version.
• conditional: support depends on the non-numeric condition shown in version_added and cannot be decided from the Lynx version alone.
• unavailable: explicitly unsupported.
• unknown: not established by the dataset.

Keep data current

Report the displayed package version with every compatibility answer. When the user asks whether the data is current, or freshness is important to the task, run:

node <skill-directory>/scripts/query-css-compat.mjs --check-updates

Use --json when structured output is useful. The check reads only the latest numeric version from the public npm registry. It does not download dataset files, modify the bundled copy, or accept cache overrides. If an update is available, report both versions and recommend updating the skill. Compatibility data changes only through reviewed skill releases that bump the pinned dependency.