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!!