How to Read This Spec

This specification uses precise language intentionally. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY carry the meanings defined in RFC 2119. These are not stylistic choices — they encode the normative force of each rule. MUST denotes a conformance requirement. SHOULD denotes a strong recommendation with defined exceptions. MAY denotes a permitted option.

Normative vs. Illustrative Content

Code blocks in this specification are normative unless explicitly marked otherwise. They define valid IDL syntax and must be reproduced accurately by conformant implementations. Example blocks are illustrative only — they demonstrate usage but do not constrain implementations beyond the normative text they accompany. When normative text and an example appear to conflict, the normative text governs.

Section Identifiers and Slug References

Each section carries a stable slug identifier displayed in breadcrumb navigation. These identifiers are guaranteed stable within a minor version and serve as canonical cross-reference targets. When citing a specific section of this specification — in RFCs, tooling documentation, or compiler error messages — use the slug, not the section title, which may change across minor versions.

Compiler Notes

Sections marked with a compiler note identify the phase (Parse, Transform, or Emit) at which a given rule is evaluated. This is informative, not normative — conformant compiler implementations may evaluate rules in different phases provided the observable behavior is identical. The canonical phase assignments reflect the reference implementation.

Version Markers

Rules introduced or modified in a minor version are marked with the version tag (e.g., v1.1). Rules present since the initial release carry no version marker. Deprecated rules are marked with the version in which deprecation was declared and the version in which they will be removed.