reaching the CSS parser

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