CSS Parser and Tokenizer API
By glazou on Sunday 8 February 2015, 01:26 - CSS and style - Permalink
The first time I mentioned the need to reach the internal CSS parser of a rendering engine from JavaScript was 17 years ago during the CSS WG meeting I hosted at Électricité de France in 1998, during a corridor discussion. All the people around said it was out of question. Then I put it back on the table in 2002, with little success again. Today, I was actioned by the CSS WG and the TAG in the Houdini Task Force to start editing a new document (with Tab Atkins, Shane Stevens and Brian Kardell) called CSS Parser and Tokenizer API. It does not say it's going to be accepted or anything, but at least it went beyond the 5 minutes chat and rebuttal. I am extremely happy and proud 
If we succeed making it happen, this is going to be a game-changer for a lot of web applications!!!
Comments
That's great, Daniel (better late than never).
Indeed, if a web developer needs CSS parsing, he will parse CSS anyway — but currently he is forced to use either a slow heavyweight full-fledged error-prone pure-JS parser or a lighter but very limited pure-JS parser. A native standardized CSS-parsing API would just make such things simpler and faster that cannot be bad at all.
What's important is that the API should be universal enough to be capable of parsing ANY valid core CSS constructs — regardless of whether a specific property, value, or at-rule, or anything else are supported by a specific browser. Otherwise the API would probably be almost useless, and pure-JS parsers would continue to be used instead. Fortunately, the "Tokenizer" word in the API title you've mentioned brings hope that the API is planned to be that universal.
Good luck.
Marat,
I agree about being universal enough. To achieve this, I think we should expose a “Parse a list of component values” algorithm described in the CSS Syntax spec: http://dev.w3.org/csswg/css-syntax/...
We’ve made sure that everything else in CSS can be defined on top of this. (Even though it can get crazy sometimes: http://dev.w3.org/csswg/css-syntax/...)
Still, component values are not super easy to work with when you want something like a CSS color. So we’ll probably want to provide parsing for higher level things as well.
Simon: Indeed, parsing things like CSS colors could also be useful, but to speed up the spec development, it could probably make sense to only define core tokenizing in the Level 1 of the spec, while higher-level things like parsing colors could probably be postponed to next levels of the spec or even defined in a separate CSS module.
Thanks Daniel, this is very exciting. What is the best place to follow the development of this document? The Houdini Task Force wiki site? A github repo?