Re: XPath & CSS, again

I disagree. My experience with XSLT says that it is quite
possible to have very good performance with a large style
sheet, having a lot of templates (and hence XPaths to match),
executed on the average web-page, which is rather small.

It is clear that performance suffers when certain contructs
are used. That is, however, a development matter, i.e. the
style sheet writer must take performance into account.

XPath introduces cases where you have to look ahead in the
document to know if the expression applies. CSS2 selectors
are very simple. You can process the document in document
order, without looking back or ahead. This is, of course, very
fast.

Note that CSS3 also introduces look ahead cases. The pseudo
classes "nth-last-child", "nth-last-of-type", "last-child",
"only-of-type" and "empty" require the availability of a
complete sibling list. So it can happen that you have to go back
in the document and reapply certain properties. This will
happen more often with XPath of course.

So with XPath as well as with CSS3 selectors it can be necessary
to keep the complete document, or large parts of it, in memory.
This is a problem for large documents. Web-pages are not that
large however.

Matching XPath expressions can be as fast as matching CSS
selectors. In both cases it is possible to generate a finite
automaton, with which you run several "threads". This means
you step through it in parallel and collect the accept states
after each step. The accept states then have to be cascaded,
according to their specificity (not available for XPath).

For XPath this is more difficult, because the generator has
to rewrite the XPath expressions in order to take into account
the structural conditions. This may result in a larger "canonic"
set of XPath expressions. It is also necessary to be able to
apply the results of the accept states to a previous node instead
of the context node. As mentioned above, this is the same for
CSS3 selectors.

Werner.

Laurens Holst wrote:
> 
> 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
> 

-- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: werner.donne@re.be

Received on Sunday, 10 April 2005 13:29:53 UTC