Re: XPath & CSS, again

Werner Donné wrote:
> Pascal,
> 
> I would welcome XPath in CSS, but then the XPath specification
> should introduce the notion of specificity, otherwise the cascading
> mechanism can't work. Look at how XSLT works around that problem
> to see how valuable cascading is.

The problem with XPath in selectors is that you cannot determine their 
outcome in O(1) or a reasonable O(n) case. With the amount of elements 
documents can have, this could very quickly result in unacceptable 
browser rendering times.

Imagine the case where you have just one style rule which has an 
//div[1]/following-sibling::*//input selector. When for every element in 
the document tree that rule is evaluated, perhaps you can see why that 
would be undesireable. Obviously as more style rules like this are 
added, the case becomes worse.

The selectors don't apply to the content, it is the other way around, 
the content finds the selectors which apply.

That is the reason why there are certain limits on which selectors in 
CSS are possible, and why XPath doesn’t fit with CSS.

Similarly an imaginative "div:apply input" selector (where :apply would 
denote that the properties apply to the div, not the input) would also 
be undesireable even though there is certainly a good use case for it, 
because here too for every element in the document tree it would have to 
be determined whether one of its children is an input element.

So, as selector XPath is a no-no in any case. For use in properties, it 
could be used, perhaps. Problem is that if some part of the document 
dynamically changes, all properties with XPath in them would have to be 
recalculated.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Received on Sunday, 10 April 2005 11:14:03 UTC