Expose CSSStyleValue hierarchy to Worker contexts

at a glance

Syntax

This feature has no new methods or properties; its syntax is the Web IDL [Exposed] change itself. The one-line diff to css_style_value.idl in CL 8085260 (fetched 2026-08-02) — the other four IDL files in the CL get the same one-line change:

  [
-   Exposed=(Window,LayoutWorklet,PaintWorklet)
+   Exposed=(Window,Worker,LayoutWorklet,PaintWorklet)
  ] interface CSSStyleValue {
    stringifier;
    // Putting Exposed=Window in the next line makes |parse| not exposed to Worklets.
    [RaisesException, Exposed=Window, CallWith=ExecutionContext] static CSSStyleValue parse(CSSOMString property, CSSOMString cssText);
    [RaisesException, Exposed=Window, CallWith=ExecutionContext] static sequence<CSSStyleValue> parseAll(CSSOMString property, CSSOMString cssText);
  };

The specification’s corresponding IDL marks every interface in the hierarchy [Exposed=(Window, Worker, PaintWorklet, LayoutWorklet)] — verified against the CSS Typed OM editor’s draft (all 36 interface declarations carry that list; extracted 2026-08-02). The TR snapshot section the ChromeStatus record links is the stylevalue-subclasses chapter of the same spec.

Contract 1: five constructors become defined in worker scopes

After the change, the following global constructors are defined in dedicated worker, shared worker, and service worker global scopes — the CL updates Blink’s webexposed/global-interface-listing expectations for exactly those three scopes (CL file list, read 2026-08-02):

Member behavior inside a worker is identical to the long-shipped Window behavior — MDN’s per-interface pages above are the member-level reference (all five verified substantive with Specifications + Browser compatibility sections, 2026-08-02); this page documents only what the exposure change makes newly reachable. The interfaces carry no [Serializable] extended attribute in the spec IDL (checked in the ED, 2026-08-02), so instances cannot be sent through postMessage() — each context constructs its own values and posts plain data (for example the stringified value) instead.

Contract 2: the parse() factories stay Window-only

The static factories CSSStyleValue.parse(), CSSStyleValue.parseAll(), and CSSNumericValue.parse() keep their member-level [Exposed=Window] attribute — the CL commit message states “The static parse()/parseAll() factories remain Window-only”, and the trunk IDL shows the member-level override on each (css_style_value.idl, css_numeric_value.idl, fetched 2026-08-02). Inside a worker, CSSStyleValue.parse is undefined even after this change: parsing arbitrary CSS text requires property-registration context a worker does not have. Workers construct values directly (new CSSUnitValue(…)) or receive plain data from the main thread.

Contract 3: what this change does not expose

The specification exposes the entire hierarchy to workers — including the transform components (CSSTransformValue, CSSTranslate, CSSRotate, …), the math family (CSSMathSum, CSSMathProduct, …), CSSNumericArray, CSSImageValue, and the color classes. CL 8085260 touches only the five core IDL files listed above, plus — per its commit message — CSSSkewX/CSSSkewY were already worker-exposed in Blink before this change. Expect the remaining subclasses to stay undefined in Chrome workers until a follow-up lands under the same tracking bug; feature-detect each constructor you need rather than inferring the whole hierarchy from one check.

Examples

No Chrome Platform Showcase demo exists for this feature yet — the expected route v153/expose-cssstylevalue-hierarchy-to-worker-contexts returned 404 on 2026-08-02, so the snippets below are gendn-derived from the sources cited on this page (not runtime-verified against a build with the CL applied — see the implementation-status warning).

// worker.js — feature-detect, then do unit math off the main thread
if (typeof CSSUnitValue === "undefined") {
  // Chrome without this change (and any browser without Typed OM in workers)
  postMessage({ supported: false });
} else {
  const width = new CSSUnitValue(480, "px");
  const doubled = width.mul(2);          // CSSNumericValue arithmetic, per MDN/spec
  const inCm = new CSSUnitValue(96, "px").to("cm");
  postMessage({
    supported: true,
    doubled: String(doubled),            // stringifier — e.g. "960px"
    inCm: String(inCm),                  // "2.54cm"
  });
}

// Receives plain data from the main thread (Contract 2: no parse() here, and
// CSSStyleValue objects are not serializable — only plain data crosses over):
self.onmessage = (event) => {
  console.log("main thread parsed:", event.data.cssText);
};

// main.js — create the worker; parsing stays on the main thread (Contract 2)
const worker = new Worker("worker.js");
worker.onmessage = (event) => console.log(event.data); // {supported, doubled, inCm}

const parsed = CSSStyleValue.parse("width", "calc(100% - 2em)"); // Window-only
// CSSStyleValue instances are not serializable — send plain data, not the object:
worker.postMessage({ cssText: String(parsed) });

web platform tests

CSS Typed OM tests under wpt/css/css-typed-om written as .any.js run in worker scopes automatically. The CL updates Blink’s baseline expectations for stylevalue-subclasses/cssKeywordValue-invalid.any.js in its .worker, .sharedworker, and .serviceworker variants (per the CL file list, read 2026-08-02) — those variants previously failed wholesale because the constructors were undefined.

Browser compatibility

Two layers matter: whether the browser has the Typed OM interfaces at all, and whether it exposes them in workers. BCD (fetched raw 2026-08-02) records the first; it has no worker-exposure subfeature rows for these interfaces, so the second layer below is sourced from the CL commit message and marked explicitly where it is unverified.

Security and privacy

The change exposes value-construction and unit-math classes to contexts that already run author script; it adds no I/O, no access to layout or computed style from workers (StylePropertyMapReadOnly exposure is unchanged by this CL and its accessors — Element.computedStyleMap(), element.attributeStyleMap — remain main-thread), and no new cross-origin surface. The ChromeStatus record lists no origin-trial, permission, or enterprise-policy considerations. Constructed values are pure data; the absence of [Serializable] means they cannot cross agent boundaries as objects.

Specifications

See also

• Chrome Platform Status — Expose CSSStyleValue hierarchy to Worker contexts (API record)
• CL 8085260 — [Typed OM] Expose core CSS Typed OM interfaces to Worker · tracking bug 534781956
• MDN: CSS Typed OM API overview · CSSStyleValue · CSSUnitValue
• webstatus.dev — css-typed-om · BCD api/CSSStyleValue.json
• Chrome Platform Showcase — expected demo route (404 as of 2026-08-02; linked for when the showcase builds it)