[csswg-drafts] [cssom] Properties that allow access to parsed-but-invalid syntactic constructs (declarations, rules, etc) as a low-fi way to make polyfills easier (#13186)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom] Properties that allow access to parsed-but-invalid syntactic constructs (declarations, rules, etc) as a low-fi way to make polyfills easier ==
In past discussions, it was always asserted that UAs need to throw invalid tokens (properties, declarations, atrules, etc) encountered during parsing away, which in turn has led to the problems around developing CSS polyfills that we end up designing entire new complex APIs to solve such as the one presented in Paris in August (which I've failed to find now).

I’m wondering if we have tested that assumption. It seems odd that there would be such vast amounts of invalid CSS code that keeping it around even in minimally processed form would incur such a significant performance impact. The UA has already done the parsing to figure out what the syntactic components are, so all we need to preserve is what has already been processed, the rest can be done lazily.

E.g. what would be the performance impact of the CSSOM having properties like:
- `CSSStyleDeclaration.prototype.source` / `CSSStyleRule.prototype.source` / `CSSStyleSheet.prototype.source` : CSS code that produced the object, before parsing. Akin to ES internal [[SourceText]].
- `CSSStyleRule.prototype.rawStyle`: like `.style` but would include all parsed declarations, whether valid or not. It doesn't need to be the same data structure as `.style`, e.g. with a data structure that supports multiple values per key (a la `URLSearchParams`) it could even preserve overidden declarations.
- `CSSStyleSheet.prototype.rawCSSRules`: like `.cssRules` but would include invalid (but parseable) rules, with a `CSSUnknownAtRule` for unknown atrules (a la HTML's `HTMLUnknownElement`).
- etc

Alternatively, we could have properties that _only_ hold invalid syntax, though then figuring out how it interleaves with valid syntax becomes difficult to impossible.

These would be:
- Lazily instantiated when accessed for the first time, so that the only thing the UA _really_ needs to keep around is their source text, which seems _fairly_ lightweight
- Non enumerable to minimize accidental reads
- Any objects pointing to *valid* syntactic components would be shared with the regular CSSOM

Later down the line we could introduce actual primitives that make polyfills even easier, such as:
- Query the tree for certain things without full traversal (e.g. which rules include a certain property?)
- Actually register certain properties/pseudo-classes/atrules/etc
- etc

But even without that, **simply *preserving* these constructs** and having a way to access them would immediately make polyfills tremendously easier, and seems relatively easy to design and ship. It could also be immensely useful for devtools and other tooling. 

Additionally, these properties can ship independently and each one immediately improves the situation even without the others.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13186 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 4 December 2025 15:44:38 UTC