Re: [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)

I agree, I'm not too fond of that idea. Seems too cumbersome and performance-degrading. I feel the data should be available passively and not be pushed actively into JS.

BTW, I think there are (at least) three distinct CSS data categories here: 1) parsable and valid/supported, 2) parsable and invalid/unsupported, and 3) invalid/malformed/unparsable. Eg. the literal text `.test { foo: bar; }` would fall under #2 because while meaningless as CSS, it is still syntactically well-formed. So the question is, what data should be made accessible via the API.

Currently, only #1 is accessible. My idea would make #2 accessible as well through the same classes and calls, however I'm worried that approach might break existing code that expects only valid and supported (#1) statements would appear in datasets.

Technically it would be possible to include #3 as well through some "raw text" property, but I'm not sure that would actually be useful for anything. Plus, I'm concerned having raw data available might open up the API to potential abuse.

-- 
GitHub Notification of comment by ravilov
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13186#issuecomment-3765712251 using your GitHub account


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

Received on Sunday, 18 January 2026 20:28:24 UTC