[cssom] Is the CSSOM ever going to preserve rules?

[matthew-dean]

Currently, browsers are instructed to discard unknown style rules. It would be great if this would change and browsers would be required to keep the rules, but flag them as unknown and not applied. This would allow a lot of style-related polyfilling in the browser (Less- or Sass-like behaviour).

Is this on the radar anywhere?

[matthew-dean]

I assume this is the related spec? https://drafts.css-houdini.org/css-properties-values-api/

[frivoal]

That is somewhat related, as the houdini project is all about exposing lower level primitives to let authors do things the browser don't, but I do not think this particular specification alone will fulfill your goals for this topic.

On the other hand, have a look here: https://github.com/WICG/CSS-Parser-API

[tabatkins]

This isn't going to happen, and fairly intentionally - if we kept around invalid/unrecognized stuff and made it easy for JS to fill in the functionality, then it would be really easy for pages to "squat" on names, making it harder for us to change or add new CSS in the future. This sort of thing is an occasional problem in JS already.

Instead, CSS is growing more robust custom-whatever functionality in the Houdini WG; custom properties are the start, and we'll move toward custom functions, custom at-rules, and others in the future. These all live in a different namespace (due to the -- prefix) which normal CSS will never use, so it's safe to use whatever names you want there.

As Florian said, we will be adding an explicit parser API that lets you re-use the general CSS syntax for other things, and that will let you manually reparse a stylesheet's text and see what all is in there without having "invalid" things thrown away, but it's a sufficient barrier to usage that it probably won't harm CSS's future evolution in the way I described above.

[matthew-dean]

Thanks @tabatkins. Is there a timeline for when the Houdini stuff / parser API might be happening?

[tabatkins]

Some parts are happening right now, and showing up experimentally in browsers, like Custom Paint and Custom Layout. The Parser API is going to end up an extension of the Typed OM spec, which is also being developed/implemented right now.

Further custom constructs (functions, at-rules) are waiting for TypedOM/parser implementation and experience before we push forward with them, as they depend on that tech.