This package contains a consolidated list of CSS features defined across specs, scraped from the latest versions of web platform specifications in webref. Fixes are applied to ensure that guarantees hold, including the ability to parse syntaxes associated with CSS features with CSSTree.
Important: If you're migrating from version 6, see the changelog for "How to upgrade" considerations.
Two async methods are exposed: listAll() and index(). They both resolve with an object that lists CSS features by feature type: atrules, functions, properties, selectors and types.
The difference between the two functions is that, under each feature type, listAll() returns an array of features, whereas index() returns an object indexed by feature name to ease direct lookups (and transition from mdn/data). Both functions return the same features.
Note: The NPM package targets JavaScript runtimes more directly but the data appears in a standalone css.json file within the package. This file may be parsed as JSON in any programming language to yield the same object as that returned by the listAll() method.
Example using listAll():
import css from '@webref/css';
const { atrules, functions, properties, selectors, types } = await css.listAll();
for (const feature of functions) {
// do something with the object that describes the CSS function
}Example using index():
import css from '@webref/css';
const { atrules, functions, properties, selectors, types } = await css.index();
// Do something with the object that describes the abs() function
const abs = functions['abs()'];Features returned by index() are indexed by their feature name, but there are exceptional cases where a given feature is defined differently (with a different syntax) for different scopes. In such cases the feature is indexed by its name completed with for and the name of the first scoping feature to which the definition applies. For example, type() for @function, type() for attr(). As of June 2025, this affects a handful of functions and types. See also the description of the for key.
The package contains data about different CSS feature types, represented by objects in the JSON structure.
Important: When a CSS feature is defined in different levels in the same spec series, the data matches the definition from the latest level. This may mean that, e.g., the syntax is more forward-looking than what is currently implemented in browsers.
Correspond to at-rules defined in CSS specs. They are listed under the atrules root key.
The following keys are always set for at-rules:
Additional keys may be set:
Correspond to at-rule descriptors defined in CSS specs. They are listed under the descriptors key of individual at-rules.
The following keys are always set for descriptors:
Additional keys may be set:
Correspond to functions defined in CSS specs and usually referenced from the syntax of other CSS features. They are listed under the functions root key.
The following keys are always set for functions:
Additional keys may be set:
Correspond to properties defined in CSS specs. They are listed under the properties root key.
The following keys are always set for properties:
Additional keys may be set:
animationTypeappliesTocanonicalOrdercomputedValueinheritedinitiallegacyAliasOflogicalPropertyGroupmedialonghandspercentagesproseresetLonghandsstyleDeclarationsyntax
Correspond to selectors defined in CSS specs. They are listed under the selectors root key.
The following keys are always set for selectors:
Additional keys may be set:
Correspond to non-terminal types defined in CSS specs and usually referenced from the syntax of other CSS features. They are listed under the types root key.
The following keys are always set for types:
Additional keys may be set:
All CSS features have:
- a
namekey that contains the name of the feature - an
hrefkey that contains the URL (with a fragment) of the CSS spec that defines the feature
In practice, all CSS features also have an extended key that contains a list of URLs of specs that extend the feature, but the key is currently only meaningful for properties. The key yields an empty array for all other features.
Many CSS features have a syntax key that describes the formal syntax of the feature, as defined in the spec. Additional keys are set depending on the type of the CSS feature.
Important: Various keys map to parts of a CSS property definition. Unless otherwise specified, values for these keys are strings extracted from the spec, without any attempt at normalizing or checking the values. Specs may use prose to define the values, either on a temporary basis or to signal specific constraints. Projects consuming the data should expect to bump into values that appear invalid or not part of the enumeration that the underlying key may be associated with.
The animationType key is only set for properties, when value is not empty. It maps to the Animation type part of a CSS property definition. Values may be one of the animation types (e.g., discrete), or prose.
The appliesTo key is only set for properties, when value is not empty. It maps to the Applies to part of a CSS property definition.
The canonicalOrder key is only set for properties, when value is not empty. It maps to the Canonical order part of a CSS property definition, which affects how CSS values are serialized.
The computedValue key is only set for properties, when value is not empty. It maps to the Computed value part of a CSS property definition.
The descriptors key is only set, and is always set, for at-rules. Value is an array of descriptor objects. The array is empty when the at-rule does not have any known descriptor. Descriptors are sorted by alphabetic order of their name.
When descriptors of an at-rule are defined in multiple specs, descriptors contains the merged list of known descriptors.
Note: The list may not be exhaustive. For example, it does not contain descriptors that are only implicitly defined in specs, such as families of properties that some at-rules accept as descriptors (e.g., @position-try).
The extended key is set for all CSS feature types, and is always set, but it is only meaningful (and not an empty array) for properties for now. Value is an array that lists absolute URLs that target the nightly version (as defined in browser-specs) of the specifications that extend a property definition. The URLs include a fragment when possible.
Note: Check the href key if you need the base definition of a property.
For example, align-items is defined in CSS Box Alignment and extended in CSS Anchor Positioning, its extended key has https://drafts.csswg.org/css-anchor-position-1/#propdef-align-items.
URLs that appear in extended are guaranteed to appear in web-specs (from the browser-specs project). See href for logic you may use to retrieve additional information about the specs.
The for key is only set for at-rules, functions and types, when value is not empty. Value is an array that lists the names of the CSS feature that the underlying CSS feature is namespaced to in the spec.
For an at-rule, names are names of other at-rules. The for relationship encodes the fact that the at-rule can only appear nested under the at-rule(s) targeted by the for key. For example, the @annotation at-rule has a for key that targets @font-feature-values.
At-rules may be nested through other means, but the data does not capture such possibilities. For example, @scope at-rules may be nested but the data does not say anything about it.
For a function or type, names may be names of properties, functions, or types. When the scoping feature is a type, its name in the for key is enclosed between < and > to make it possible to disambiguate between the possibilities: any name that starts with < and ends with > targets a type, any name that ends with () targets a function, any other name targets a property. The for relationship captures the fact that the function or type can only appear in the context of the scoping property, function, or type. For example, the blur() function has a for key that targets the filter property.
There exist a handful of functions and types that are defined with different syntax for different scopes. In such cases, there exist multiple entries in the list with the same name key but different for keys. For example, the fit-content() function has two entries with slightly different syntaxes:
- one for
grid-template-columnsandgrid-template-rows, - the other for
height,max-height,max-width,min-height,min-width, andwidth.
CSS features targeted by for keys are guaranteed to exist.
The href key is set for all CSS feature types, and is always set. Value is a string representing an absolute URL (with a fragment) that targets the main definition of the underlying CSS feature in the nightly version (as defined in browser-specs) of the spec that defines it.
The href key always targets the base definition of a CSS feature. Check the extended key to gather information about possible extensions.
For example:
https://drafts.csswg.org/css-values-4/#funcdef-absfor theabs()function.https://drafts.csswg.org/css-display-4/#propdef-displayfor thedisplayproperty. The property is extended in CSS Ruby buthrefrather targets the base definition in CSS Display.
URLs that appear in href are guaranteed to appear in web-specs (from the browser-specs project). You may use the following logic if you need to retrieve information about the underlying specs, (note that it also gathers information about extensions):
import webref from '@webref/css';
import webspecs from 'web-specs' with { type: 'json' };
const css = await webref.listAll();
for (const category of Object.keys(css)) {
for (const feature of css[category]) {
const featureSpecs = [feature.href, feature.extended ?? []]
.flat()
.map(href => {
// Get rid of the fragment to ease mapping to spec URLs
const url = new URL(href);
url.hash = '';
return url.toString();
})
// Note: some specs don't have a "nightly" version in web-specs.
// They are not crawled, no CSS content in them
.map(url => webspecs.find(spec =>
[spec.nightly?.url, spec.nightly?.pages].flat().includes(url)
));
const markdown = featureSpecs
.map(s => `[${s.title}](${s.nightly.url})`)
.join(', ');
console.log(`- Sources for ${feature.name}: ${markdown}`);
}
}The inherited key is only set for properties, when value is not empty. It maps to the Inherited part of a CSS property definition.
The initial key is only set for properties, when value is not empty. It maps to the Initial part of a CSS property definition.
Note: Value is a valid syntax most of the time, but there is no guarantee that this is always the case (See also issue #707).
The legacyAliasOf key is only set for properties that are legacy name aliases of another property. Value is the name of the newer property. For example, -webkit-align-content is a legacy name alias for align-content.
Note: A number of legacy properties defined in Compatibility map to new properties, but are not legacy name aliases for these properties and do not have a legacyAliasOf key as a result. For example, -webkit-box-align maps to box-align but is not a legacy name alias for box-align.
The logicalPropertyGroup key is only set for properties, when value is not empty. It maps to the Logical property group part of a CSS property definition.
The longhands key is only set for shorthand properties. Value is an array that lists the names of the longhand sub-properties that the shorthand property sets, in specification order.
For example, the background-position shorthand property lists background-position-x and background-position-y as longhands values.
Longhand sub-properties may themselves be shorthand properties. For example, border is defined as a shorthand for border-width, border-style and border-color and, e.g., border-width is itself a shorthand for border-top-width, border-right-width, border-bottom-width and border-left-width. Expand all longhand sub-properties to get the full list of longhands that a shorthand property sets.
Note: Shorthand properties may also reset a few properties to their initial value without setting them. Reset-only sub-properties are listed in the resetLonghands key.
The media key is only set for properties, when value is not empty. It maps to the Media groups part of a CSS property definition.
The name key is set for all CSS feature types, and is always set. It contains the name of the feature as a string.
Within a feature type, names are generally unique... provided that one considers the for key to account for the cases when the syntax of the CSS feature differs depending on the context.
Notes:
- At-rule names start with
@. For example,@media. - Function names end with
(). Parameter names are never provided in the name itself but appear in the syntax (seesyntaxkey). For example,abs(). - Property names appear as defined. For example,
animation-duration. - Legacy property names may start with
-. For example,-webkit-mask. - With the exception of combinators (
+,&,~,>,||), selector names start with one (or two):. For example,:visited. - Selectors that are also functions end with
(). For example,:is(). - Type names are not wrapped in enclosing
<>. For example,angle.
The percentages key is only set for properties, when value is not empty. It maps to the Percentages part of a CSS property definition.
The prose key is set for all CSS feature types, when value is not empty. It contains a text excerpt from the spec near the definition of the CSS feature. The value is more intended for human review and debugging purpose. It should not be used for documentation purpose, both because it does not faithfully describe the feature at hand and because it may contain unrelated prose.
The resetLonghands key is only set for shorthand properties. Value is an array that lists the names of the reset-only sub-properties that the shorthand reset to their initial values, in specification order.
Reset-only sub-properties may themselves be shorthand properties. Expand all reset-only sub-properties to get the full list of longhands that get reset by a shorthand.
For example, the border shorthand property has border-image in resetLonghands, and border-image is a shorthand for border-image-source, border-image-slice, border-image-width, border-image-outset and border-image-repeat.
Note: See also the longhands key for the list of longhand sub-properties that a shorthand property sets.
The styleDeclaration key is only set, and is always set, for properties. It contains the list of IDL attribute names that the property generates, as defined in CSS Object Model, in other words, the names that would replace _camel_cased_attribute, _webkit_cased_attribute, _dashed_attribute in:
partial interface CSSStyleDeclaration {
[CEReactions] attribute [LegacyNullToEmptyString] CSSOMString _camel_cased_attribute;
};
partial interface CSSStyleDeclaration {
[CEReactions] attribute [LegacyNullToEmptyString] CSSOMString _webkit_cased_attribute;
};
partial interface CSSStyleDeclaration {
[CEReactions] attribute [LegacyNullToEmptyString] CSSOMString _dashed_attribute;
};The list may contain one, two, or three names, depending on the number of names that the property generates. For example:
- The
widthproperty only generates awidthIDL attribute. - The
white-spaceproperty generateswhite-spaceandwhiteSpaceIDL attributes. - The legacy
-webkit-align-contentproperty generates-webkit-align-content,WebkitAlignContent,webkitAlignContentIDL attributes.
Most CSS features have a syntax key that contains a string that describes the formal syntax of the feature, as defined in the spec. For properties, this syntax maps to the Value part of the CSS property definition.
Note: The syntax aligns with the spec and does not include historical values and proprietary extensions that browsers may support.
Patches are applied to the values extracted from the specs to guarantee that the value of a syntax key can always be parsed with the CSSTree Value Definition Syntax parser. Example:
import css from '@webref/css';
import { definitionSyntax } from 'css-tree';
const { properties } = await css.index();
const ast = definitionSyntax.parse(properties['flex'].syntax);
// do something with the abstract syntax treeWhen a property is extended with new values in different specs, the syntax key contains the union (using |) of the syntaxes of the base and extended definitions.For example, the syntax (as of March 2026) of the top property is auto | <length-percentage> | <anchor()> | <anchor-size()>, noting that the former part of the syntax comes from CSS Position while the latter part comes from CSS Anchor Positioning.
Note: There is no guarantee that functions, properties and types referenced in the syntax actually exists. The grammar is known to be incomplete.
The type key is only set for properties, when value is not empty. It maps to the Media feature type part of a CSS property definition. Value should be one of discrete or range, but data may contain additional values depending on what specs actually define.
The structure of the consolidated list of CSS features aligns with CSS data in mdn/data. If you use the index() method, the @webref/css package can almost serve as a drop-in replacement for the mdn/data package for syntaxes, with the following structural nuances:
mdn/datareports at-rules under anatRuleskey.@webref/cssreports them under anatruleskey.mdn/datastores syntaxes of functions and types under a separatesyntaxeskey.@webref/cssstores them in their feature definition. If you need to reproduce thesyntaxeslist, merge the entries underfunctionsandtypes.mdn/dataassumes all features are unscoped.@webref/cssreports scopes where needed in aforkey. Note that a few functions have a different syntax depending on the scope under which they are used.@webref/cssdoes not contain information about CSS units.
Beyond structural nuances, differences in content may also affect transition:
mdn/datacontains deprecated features, proprietary features or feature variants that are not defined in specs.@webref/cssonly contains features defined in specs.mdn/datadescribes features as implemented in main browsers.@webref/css"lives on the edge", listing features and syntaxes from latest levels of CSS specs, regardless of the spec's maturity level and support across browsers.mdn/dataturns specs prose into syntax when needed,@webref/cssonly has syntaxes that are explicitly defined in specs. It should be possible to improve the specs, consider submitting missing syntax reports (against the specs themselves if possible, in Webref otherwise).
The following guarantees are provided by this package:
- All syntax values (the
syntaxkeys) can be parsed by the version of CSSTree set inpeerDependenciesinpackage.json. - Feature names (the
namekeys) are unique per type provided that theforkey is also taken into account for functions and types. - CSS features targeted by
for,legacyAliasOf,longhandsandresetLonghandskeys are guaranteed to exist in the package. - All features have an
hrefkey that targets the CSS spec that defines the feature. When the feature is extended across CSS specs, this URL targets the base definition. - All URLs (without fragment) that appear in
hrefandextendedkeys are guaranteed to exist in the version ofweb-specsthat was used to identify the specs to extract data from. The exact version that was used is not yet surfaced in the data though. In most cases, it should be the latest published version at the time when the data is released.
There is no guarantee that:
- Functions, properties and types referenced by other constructs actually exist. The grammar is known to be incomplete.
- Key values can be parsed with a formal grammar or map to a closed set of values, except for
styleDeclarationandsyntaxkey values.