[
Lists Home |
Date Index |
Thread Index
]
Norman Walsh wrote:
> / "Simon St.Laurent" <simonstl@simonstl.com> was heard to say:
> | Sure, though I'll admit that one of my projects with MOE is supporting
> | CSS both as an annotation and as an explicit CSS-in-XML syntax.
>
> CSS-in-XML sounds like a good idea. Let's see, it's a bag of
> properties attached to a CSS Selector. (<rant>What happened to the
> Last Call comments to rename the "Selectors" document[1] to "CSS3
> Selectors". More paperwork to dig through...Sigh.</rant>)
>
> The bag of properties thing would be easy to deal with, but the set of
> selectors is starting to look awfully ugly. "nth-last-child()"...Eeek!?
> Simplicity is loosing everywhere, ain't it?
Do we really want or need to convert those selectors to XML? CSS-in-XML
is a discussion that surfaces every three to six months on a number of
mailing lists. Basically it would seem that you want to convert the
selectors to XML if your goal is to munge them using basic XML tools
(say display them with syntax colouring using XSLT) but you don't if
you're looking for an easy way to decorate a tree (and would prefer an
XML syntax ovre SAC, which is a largish underspecified API, at least
compared to SAX).
Converting CSS selectors to XPath shouldn't be excessively complex
provided we allow ourselves to use a few extension functions where there
is no possible mapping and drop the interactivity bits. Most of the
structural selectors can be mapped directly, and a number of the more
complex-looking ones can probably be converted to predicates revolving
around position() and a little arithmetic. Imho the useful 80% of CSS
selectors can be covered by XPath, with the exclusion of class that will
probably need an extension function by itself.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
|
