unrecognized CSS properties are not accessible through CSSStyleDeclaration
Categories
(Core :: DOM: CSS Object Model, enhancement)
Tracking
()
People
(Reporter: martin.honnen, Unassigned)
Details
Attachments
(1 file)
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
Updated•20 years ago
|
Comment 6•19 years ago
|
||
Comment 10•16 years ago
|
||
Updated•16 years ago
|
Comment 11•15 years ago
|
||
Comment 12•14 years ago
|
||
Comment 13•9 years ago
|
||
Comment 14•9 years ago
|
||
Comment 15•9 years ago
|
||
Comment 16•9 years ago
|
||
Updated•3 years ago
|
Comment 17•1 year ago
|
||
One very good reason to "pass through" unknown/unrecognized/"invalid" declarations (property-value pairs) via one or the other CSS API -- whether an existing one like Window::getComputedStyle
or something else where one can obtain these values after the UA has already had a pass at parsing e.g. a stylesheet -- is to enable "polyfilling" CSS modules. For instance, consider the very fresh "CSS Anchor Positioning" spec., which Google and Mozilla already have declared intent to implement (meaning it's well on the way to become a standard). If I were to write some pop-up logic for a site, I could just invent my own API or -- in light of the fact the former will most likely find its way into Firefox and Chrome/Edge -- just "polyfill" an implementation while anticipating native support, at which point I at least won't have to re-factor the client code (ideally) or even remove polyfilling (which by nature is conditional on missing support).
The problem with "polyfilling" an implementation of the aforementioned CSS specification, has to do with the fact that, like most spec's of the kind, it introduces new CSS properties, like anchor-name
etc. A "polyfill" would depend on being able to at least find the declarations of these properties in style objects through e.g. a script, so that it can implement their interpretation and so on -- anchoring elements as specified.
But I can't -- since the CSS parser "strips" or effectively "hides" the declarations UA doesn't support for this or that module.
A recourse might be to implement a CSS parser in a script, and feed every one of the same stylesheet(s) that is already linked to the document, as means to locate properties like anchor-name
which the "native" CSS APIs do not vend and pretend were never there. But such an alternative in my opinion borders on insanity what regards cost-benefit -- if I were to consider my immediate problem of implementing pop-ups in some reusable fashion, such that e.g. need anchoring on non-ancestor elements which is what the aforementioned spec. describes, it would be a much more sound investment to just write a script that does this without any claim to alignment with some spec that requires access to novel properties.
As for solutions to the "we can't make the parser vend invalid properties because that would break CSS [2] compatibility" problem -- what if CSS introduced the kind of document conformance not unlike (conceptually) HTML "doctype" definition? E.g. through a new at-rule like @version
, somehow specifying compliance intent. None of the existing stylesheets, by the nature of things, would be featuring such rule and thus can have the parser/APIs stay in the "quirk" mode (backwards-compatible), while stylesheets featuring e.g. @version 4;
can allow the UA to behave in a manner where unknown properties are visible to and usable by API clients?
Description
•