Specified behavior and implemented behavior diverge

What it is

The web has two layers of “correct.” A public standard says how elements, CSS, and APIs should behave, and Chromium, WebKit, and Gecko each say how they do. Date pickers, dialogs, scroll chaining, clipboard, fullscreen, and flex minimum sizes are often defined in the standard and realized as three widgets, three defaults, and three bugs. A wireframe drawn to the spec and accepted in one engine is a product that holds in your browser, not in the user’s.

The gap is not a temporary defect list. Engines ship on different clocks, and mobile WebKit keeps behaviors that desktop engines have left behind. Waiting until “everyone implements it” hands the release date to the slowest engine.

Why it happens

A standard is negotiated text; an implementation is code with history. Where the standard leaves details unspecified, engines fill them with their own widget chrome, focus order, and performance tradeoffs. After vendor prefixes, features ship under unprefixed names; the same name no longer guarantees the same behavior. position: sticky, <input type="date">, dialog, and whether overflow passes a wheel event to the parent are aligned in name and forked in meaning. Mobile adds another split: the system browser’s engine is often a frozen WebKit generation, so an API that works in desktop Chrome is simply absent on the phone.

“Supported in the standard” therefore cannot be read off a green cell in a compatibility table. The cell says an API exists; it does not say the widget chrome, keyboard behavior, accessibility tree, or error states are usable. A design that treats an unaligned detail as platform convention—assuming every date picker has a Cancel control—mistakes one engine’s implementation for the web.

Where it stops holding

An embedded WebView aimed at a single engine (an enterprise shell, some mini-program kernels) can treat that engine as fact; the gap shrinks to the shell’s upgrade cycle. Print stylesheets, e-readers, and mail clients are a different kind of incomplete implementation; the browser-engine gap model does not transfer. The frozen, highly aligned subset—basic flow, links, form GET/POST—barely diverges; it does not need an engine fork. Automation that runs in one engine will not see this gap. A green suite and user complaints can coexist.

Applying it

• Write critical interactions as two columns: standard intent, and what each engine actually does. Walk date, dialog, scroll, clipboard, file picking, and fullscreen on Chromium, WebKit, and Gecko, and record widget chrome and failure states—do not stop at the support table.
• Where behavior still forks, do not fake a unified widget. Wrap it in application UI, or accept that system widgets will look different per engine.
• Accept mobile WebViews separately from desktop browsers; a desktop pass is not a mobile pass.
• Verify by opening the same critical path in three engines and listing the steps that disagree. Any step completable in only one engine, or a widget missing Cancel/Close, treated an implementation as the standard. Put that list on the release gate instead of shipping it as a known issue.

Related

• Same group: R4.05.2 Mobile browsers have distinctive viewport and keyboard behavior · R4.05.3 Progressive enhancement is the basic strategy for divergence
• Adjacent: R4.14 The consistency cost of cross-platform frameworks · R3.16 Low-end devices and degradation
• Search terms: spec-implementation gap · engine divergence · WebKit · Chromium