Re: XPath as CSS-selectors?

Asbjørn Ulsberg wrote:
> Chris Lilley wrote:
>>For example, it would be trivial to make an XPath selector
>>that would block all CSS rendering by making the styling of
>>the first element be dependent on an attribute on the last
>>element.
> 
> Excuse me for being dumb, but I don't quite understand what
> you mean. Can you please give an example?

Browsers typically render as they see things. That is, for a long document, 
you'll start seeing rendering before the document is loaded. I believe that 
browser makers feel quite strongly about this (and rightly so). If however the 
rendering of the first element depended on some information in the last one (eg 
/*/following-sibling::*[last()]/@foo) that wouldn't be possible.

>>And Xpath does not have the equivalent of pseudo-elements or
>>pseudo-classes.
> 
> As I wrote to Ian, this can be combined.

Or you could have XPath functions. But why bother? CSS is widely deployed in 
browsers. Why fix something that ain't broken?

>>Ian, in general, I agree that XPath was designed more for a
>>batch-oriented, one-shot transformation process like XSLT
>>rather than for a continuously evaluated dynamic system like
>>CSS.
> 
> The language's design don't exclude it from being used in other
> areas or environments, though it might set some constraints on
> it.

I think a full fledged comparison of what can be done with either would be very 
interesting indeed. I wouldn't be surprised if subtle differences in design made 
worlds of difference in highly dynamic situations. XForms isn't typically highly 
dynamic, XForms aren't usually meant to move and change all the time. XHTML and 
SVG however, are much more likely to require frequent reevaluation.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Thursday, 19 June 2003 09:04:38 UTC