webref
repository·main·Indexed 19 days ago
https://github.com/w3c/webrefMachine-readable references and analyses of terms defined in web browser specifications, providing automatically extracted components for CSS, Web IDL, and HTML elements. It is used by tools such as Web Platform Tests (WPT) to ensure correct implementation of web standards. The project includes packages like @webref/css for accessing CSS feature definitions, @webref/idl for Web IDL, @webref/elements, and @webref/xref for specification lookups.
What's inside webref
- CDDL patches are modifications applied to the Constraint Description Definition Language (CDDL) extracts that are scraped directly from web specifications. Because specification updates can change the structure of the scraped data, these patches require ongoing maintenance to ensure the extracts remain accurate and valid.
Overview of Webref machine-readable references
mainWebref provides machine-readable extracts of web platform definitions (CSS properties, Web IDL, HTML elements, events, etc.) automatically extracted from browser specifications.
There are two main types of data available:
- Raw Extracts (
mainbranch): Automatically generated from specifications. These have no guarantees regarding validity or consistency and may contain invalid IDL snippets or unknown types. - Curated Extracts (
curatedbranch): Generated from raw extracts by applying manually-maintained patches to fix invalid content and ensure validity and consistency. These are published athttps://w3c.github.io/webref/ed/.
Recommendation: Unless you are prepared to handle invalid content, use the
curatedbranch or the provided NPM packages instead of themainbranch.- Raw Extracts (
How freeze patches work
mainFreeze patches are used to lock the extracts for a specific specification to a historical state. This is achieved by applying a patch that points to a specific commit ID in the Webref repository, ensuring that the crawl results for that spec remain consistent with that past result.
To implement a freeze patch, create a JSON file named after the specification's shortname. The file must contain a JSON object with the following keys:
commit: The full commit ID in Webref that identifies the specific crawl results to be used for the spec.pending: The URL of a tracking issue. This is used to identify when the underlying problem has been resolved and the patch can be removed.
{ "commit": "<full-webref-commit-id>", "pending": "<url-to-tracking-issue>" }Data guarantees in @webref/elements
mainThe
@webref/elementspackage provides the following data integrity guarantees:- Interface Consistency: All Web IDL interfaces listed in the element data are guaranteed to exist in the latest version of the
@webref/idlpackage at the time of the@webref/elementsrelease. - Link Integrity: All elements include an
hrefproperty that links back to their official definition in the specification.
- Interface Consistency: All Web IDL interfaces listed in the element data are guaranteed to exist in the latest version of the
Understand the structure of an event object
mainEach event object returned by
listAll()contains the following properties:type: The name of the event.interface: The Web IDL interface used by the event.targets: A non-empty list of objects describing where the event may fire. Each target object includes:target: The name of the interface.bubbles: (Optional) A boolean indicating if the event bubbles. This is only set for interfaces belonging to a bubbling tree (e.g., DOM, IndexedDB, Serial API, Web Bluetooth).bubblingPath: (Optional) A list of core interfaces on which the event can theoretically bubble. This is only set when the event effectively bubbles.
href: (Optional) A URL to the event's definition in a specification.src: (Optional) A description of where the extraction first detected the event in the spec.
Note on Bubbling: The
bubblingPathcontains core interfaces like["Node", "Document", "Window"]. While an event might fire on a specific element likeHTMLSelectElement, the path represents the theoretical bubbling hierarchy. Actual bubbling behavior depends on the inheritance of the target interface.const events = require('@webref/events'); events.listAll().then(all => { for (const event of all) { console.log(`Event type=${event.type} interface=${event.interface} targets=${event.targets .map(t => t.target + (t.bubbles === undefined ? '' : ` (bubbles: ${t.bubbles})`)) .join(', ')}`); } });Understand the types of CSS patches in Webref
mainThe
@webref/csspackage uses two distinct types of patches to correct CSS extracts scraped from specifications:Syntax Patches (
syntax-patches.js): Used for syntaxes that cannot be automatically extracted because they are defined in non-machine-readable prose. These are generally permanent. To propose a new syntax patch, use the dedicated issue template.File Patches (
*.json.patch): These are applied to specific extract files. They are intended to be temporary fixes for issues in the underlying specification. Because they target specific file versions, they are prone to breaking when specifications are updated. For instructions on managing these, refer to the Web IDL patches documentation.
Understand Webref data curation guarantees
mainWebref provides curated extracts of web platform definitions (Web IDL, CSS, Elements, Events, and CDDL) with specific quality guarantees. Consumers can rely on these guarantees to ensure the data is syntactically valid, uniquely defined, and correctly linked to official specifications.
Web IDL extracts
- Parsable by the version of
webidl2.jsinpackage.json. - Passes
WebIDL2.validate(except for the[LegacyNoInterfaceObject]rule). - All types and extended attributes are defined by a specification.
- No duplicate top-level definitions, mismatched types in inheritance, or conflicts in mixins/partials.
CSS extracts
Note: Since
@webref/cssversion 7, CSS data is provided via a single consolidateded/css.jsonfile rather than per-spec extracts.- All
syntaxvalues are parsable by theCSSTreeversion inpeerDependencies. - Feature names (
namekeys) are unique per type (considering theforkey). - All features targeted by
for,legacyAliasOf,longhands, andresetLonghandsare guaranteed to exist. - Every feature includes an
hrefkey targeting the base CSS specification. - All URLs in
hrefandextendedkeys are guaranteed to exist in theweb-specsversion used during extraction.
Elements extracts
- All Web IDL interfaces referenced by elements exist in the Web IDL extracts.
- All elements link back to their definition in the specification.
Events extracts
Provided via the consolidated
ed/events.jsonin the@webref/eventspackage:typematches the event name.interfacedescribes the actual Web IDL interface (not a mixin) and exists in the latest@webref/idlversion at release.targetsis a non-empty list of target interfaces (actual interfaces, not mixins) existing in the latest@webref/idl.bubblesis a boolean for target interfaces in a bubbling tree (DOM, IndexedDB, etc.) and is only set for such interfaces.bubblingPathis only set if the event actually bubbles on that interface.targetscontains the top-most interface in an inheritance chain (unless bubbling differs) and the deepest interface in a bubbling tree on which the event may fire.
CDDL extracts
- All CDDL files pass analysis by the
Strudyversion inpackage.json(parsable bycddlparser). - Note: CDDL extracts are not currently released as an NPM package.
- Parsable by the version of
Understand the parsing and consistency guarantees of @webref/idl
mainThe
@webref/idlpackage provides several technical guarantees regarding the quality and consistency of the scraped Web IDL definitions:Parsing Guarantees
- All IDL files are guaranteed to be parsable by the version of
webidl2.jsspecified in the package'speerDependencies. WebIDL2.validatepasses for all files, with the single exception of theno-nointerfaceobjectrule (due to the wide use of[LegacyNoInterfaceObject]).
Structural Guarantees
- All types and extended attributes are defined by a specification.
- There are no duplicate top-level definitions or members.
- Inheritance chains contain no missing or mismatched types.
- There are no conflicts when applying mixins and partials.
Limitations (What is NOT guaranteed)
- Extended attribute values are not validated.
- No other guarantees are provided beyond those enforced by the package's internal tests.
- All IDL files are guaranteed to be parsable by the version of
Understand CSS feature keys in @webref/css
mainThe
@webref/csspackage provides structured data for CSS features (at-rules, descriptors, functions, properties, selectors, and types). Every feature includes anameand anhref(the base specification URL).Important Data Integrity Note: Many keys map to parts of a CSS property definition as raw strings extracted from the spec. These values are not normalized or checked. Consumers should expect values that might appear invalid or do not match an expected enumeration because they may contain prose from the specification used to define constraints.
Understand Element patches in @webref/elements
mainElement patches are used to modify the raw elements extracts scraped directly from web specifications. These patches are applied to the scraped data to produce the final@webref/elementspackage. Because these patches depend on the structure of specifications, they may break when specs are updated and require ongoing maintenance to ensure the@webref/elementspackage remains accurate.Understand @webref/css data guarantees
mainThe
@webref/csspackage provides several structural and parsing guarantees:- CSSTree Compatibility: All values in the CSS files can be parsed by the version of CSSTree specified in the package's
peerDependencies. - Uniqueness: No duplicate definitions of entries (properties, at-rules, selectors, types, or functions) exist in the CSS files, provided that delta specs (files ending in
-n.json) are not included. - Base Definitions: CSS extracts contain base definitions for all properties; other definitions that extend these will use the
newValueskey. - Traceability: Most entries under
properties[],properties[].values[],selectors[],atrules[], andvalues[]include anhrefkey containing an absolute URL with a fragment pointing to the original specification definition.
Exceptions to Traceability:
- Properties that have a
newValueskey. - At-rules that lack both a
proseand avaluekey. - Definitions from a delta spec that completely override a previous level's definition.
- CSSTree Compatibility: All values in the CSS files can be parsed by the version of CSSTree specified in the package's
How CSS property duplicates are handled
mainDuring the curation process, duplicate CSS definitions are removed using thetools/drop-css-property-duplicates.jsscript. This ensures that when multiple specifications define the same property, the correct definition is preserved (for example, ensuring that definitions in CSS Modules override definitions in CSS 2).