- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Tue, 23 Dec 2014 08:57:56 +0100
- To: public-wtf@w3.org
To prepare the Sydney meeting, I would like to come back to one of the things we discussed in Santa Clara, exposing the parser. All polyfills - and our world is full of polyfills - rely on CSS parsing. 1. parse a selector and get an object representing it 2. extend querySelector() to namespaces 3. parse a value and get an object representing it 4. parse a complete stylesheet 5. access to unknown properties and values 6. add a new pseudo-class or functional pseudo-class to the parser, attached to some JS code replying a boolean 7. add a new property to the parser, to allow layout experiments through the box tree Item 1 is about exposing the construct all browsers have for selectors. That's necessary at least because of item 3 since a value can be a selector. Item 2 is an issue in our OM we have been keeping under the radar for far too long, IMHO, and that we need to solve for item 1. Item 3 is a major thing. We don't want all JS codes around to reparse complex values like gradients or background images. I wrote some thoughts about it at [1], this is only informational. Item 4 is an old hole in the CSS OM where rules have a cssText attribute but stylesheets haven't... Item 5 is mandatory if we want all of this to be used as an extensibility mechanism by polyfills. I have been fighting a lot with that one, since it is a key element for content editors. We already discussed a bit item 6, an old dream of mine I suggested eons ago. Item 7 is not less important to polyfills than item 5. Opinions? [1] http://www.glazman.org/weblog/dotclear/index.php?post/2014/03/19/A-better-CSS-OM-for-parsed-values </Daniel>
Received on Tuesday, 23 December 2014 07:58:19 UTC