# Lynx Check CSS Support

> Query @lynx-js/css-defines compat_data to check Lynx CSS property and nested feature/value support by rendering backend and Lynx version, or check whether a newer dataset version exists. Use when asked whether CSS is supported in Lynx or ReactLynx, which backends support it, when support was added, whether a style change is compatible, whether the bundled data is current, or when inspecting the raw definition JSON.

- Skill: `lynx-community/lynx-check-css-support` (Agent Skill, multi-file: 241 files)
- Install (CLI): `npx skillmds add lynx-community/lynx-check-css-support`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lynx-community/lynx-check-css-support/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: lynx-community (https://skillmd.com/u/lynx-community)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/lynx-community/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:

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

Query the property's base compatibility across every backend:

```bash
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.

```bash
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.

```bash
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:

```bash
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.