webref

repository·main·Indexed 19 days ago

https://github.com/w3c/webref

Machine-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.

Tokens
11.4K
Snippets
25
Records
42
Agent score
66%

What's inside webref

  1. Overview of CDDL patches

    main
    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.
  2. Overview of Webref machine-readable references

    main

    Webref 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:

    1. Raw Extracts (main branch): Automatically generated from specifications. These have no guarantees regarding validity or consistency and may contain invalid IDL snippets or unknown types.
    2. Curated Extracts (curated branch): Generated from raw extracts by applying manually-maintained patches to fix invalid content and ensure validity and consistency. These are published at https://w3c.github.io/webref/ed/.

    Recommendation: Unless you are prepared to handle invalid content, use the curated branch or the provided NPM packages instead of the main branch.

  3. How freeze patches work

    main

    Freeze 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>"
    }
  4. Data guarantees in @webref/elements

    main

    The @webref/elements package provides the following data integrity guarantees:

    1. Interface Consistency: All Web IDL interfaces listed in the element data are guaranteed to exist in the latest version of the @webref/idl package at the time of the @webref/elements release.
    2. Link Integrity: All elements include an href property that links back to their official definition in the specification.
  5. Understand the structure of an event object

    main

    Each 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 bubblingPath contains core interfaces like ["Node", "Document", "Window"]. While an event might fire on a specific element like HTMLSelectElement, 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(', ')}`);
      }
    });
  6. Understand the types of CSS patches in Webref

    main

    The @webref/css package uses two distinct types of patches to correct CSS extracts scraped from specifications:

    1. 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.

    2. 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.

  7. Understand Webref data curation guarantees

    main

    Webref 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.js in package.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/css version 7, CSS data is provided via a single consolidated ed/css.json file rather than per-spec extracts.

    • All syntax values are parsable by the CSSTree version in peerDependencies.
    • Feature names (name keys) are unique per type (considering the for key).
    • All features targeted by for, legacyAliasOf, longhands, and resetLonghands are guaranteed to exist.
    • Every feature includes an href key targeting the base CSS specification.
    • All URLs in href and extended keys are guaranteed to exist in the web-specs version 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.json in the @webref/events package:

    • type matches the event name.
    • interface describes the actual Web IDL interface (not a mixin) and exists in the latest @webref/idl version at release.
    • targets is a non-empty list of target interfaces (actual interfaces, not mixins) existing in the latest @webref/idl.
    • bubbles is a boolean for target interfaces in a bubbling tree (DOM, IndexedDB, etc.) and is only set for such interfaces.
    • bubblingPath is only set if the event actually bubbles on that interface.
    • targets contains 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 Strudy version in package.json (parsable by cddlparser).
    • Note: CDDL extracts are not currently released as an NPM package.
  8. Understand the parsing and consistency guarantees of @webref/idl

    main

    The @webref/idl package 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.js specified in the package's peerDependencies.
    • WebIDL2.validate passes for all files, with the single exception of the no-nointerfaceobject rule (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.
  9. Understand CSS feature keys in @webref/css

    main

    The @webref/css package provides structured data for CSS features (at-rules, descriptors, functions, properties, selectors, and types). Every feature includes a name and an href (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.

  10. Understand Element patches in @webref/elements

    main
    Element 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/elements package. Because these patches depend on the structure of specifications, they may break when specs are updated and require ongoing maintenance to ensure the @webref/elements package remains accurate.
  11. Understand @webref/css data guarantees

    main

    The @webref/css package 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 newValues key.
    • Traceability: Most entries under properties[], properties[].values[], selectors[], atrules[], and values[] include an href key containing an absolute URL with a fragment pointing to the original specification definition.

    Exceptions to Traceability:

    • Properties that have a newValues key.
    • At-rules that lack both a prose and a value key.
    • Definitions from a delta spec that completely override a previous level's definition.
  12. How CSS property duplicates are handled

    main
    During the curation process, duplicate CSS definitions are removed using the tools/drop-css-property-duplicates.js script. 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).