10.11 — The Living Standard Workflow & Modern Evolution

The Rise of the Living Standard

The traditional W3C model defined HTML versions like HTML4 and XHTML as fixed snapshots. This approach failed: committees debated features without real‑world code, leading to divergent browser implementations and a fractured web.

In 2004, browser engineers formed the WHATWG and established a radical principle: HTML has no version number. Instead, the Living Standard is a continuously updated specification that reflects the actual, running code in browsers. The standard follows the implementation, not the other way around.

The Feature Lifecycle

1. Proposal & Incubation – Engineers identify a platform gap and submit an explainer to the Web Incubator Community Group (WICG). Early discussion shapes the API shape.
2. Experimental Implementation – Browser teams (Chromium, WebKit, Gecko) prototype the feature in their engine’s source code, often behind a flag. They map new C++ node classes, update the tokenizer, and expose JavaScript bindings.
3. Specification Refinement – The standard text is updated continuously to match the implementations. Edge cases discovered during coding are fed back into the spec.
4. Interoperability & Convergence – Only when multiple engines produce identical behaviour for the feature does it graduate from “draft” to “standard.” This convergence is verified by Web Platform Tests (WPT).

Web Platform Tests – The Convergence Enforcer

Web Platform Tests is a massive, shared test suite maintained by all browser vendors. It contains millions of tests that verify:

• HTML parser tokenization and error recovery produce identical DOM trees.
• DOM interface inheritance chains match the specification.
• Layout and paint operations yield consistent pixel results.

Every build of every browser engine runs the WPT suite. A feature cannot ship to stable without passing these tests, guaranteeing a baseline of interoperability.

User‑Agent Sniffing vs. Feature Detection

User‑Agent sniffing reads navigator.userAgent and tries to deduce what the browser supports. It is a legacy anti‑pattern: strings can be spoofed, legacy browsers cannot predict future features, and engine internals change without updating the identifier.

Feature detection directly queries the runtime to verify if a capability exists before using it. This is the only reliable, future‑proof strategy.

// ❌ Sniffing – never do this
if (navigator.userAgent.includes('Chrome')) { ... }

// ✔ Feature detection in JavaScript
if ('showModal' in HTMLDialogElement.prototype) {
    dialog.showModal();
} else {
    // Fallback polyfill
}

CSS Feature Queries & Progressive Enhancement

The same defensive strategy applies in CSS using @supports:

/* Baseline layout */
.card { display: block; }

/* Enhanced layout for modern engines */
@supports (display: grid) {
    .card { display: grid; }
}

The style engine evaluates its own capabilities. If it understands grid, the advanced rules apply; if not, the element gracefully falls back to block layout. The browser’s fault‑tolerant CSS parser silently ignores unknown properties, so there’s never a crash.

This is progressive enhancement: build a solid, accessible baseline using fundamental HTML and CSS, then layer on advanced features conditionally. Every user gets a working experience; capable engines get the best possible version.