W3C home > Mailing lists > Public > www-style@w3.org > June 2003

Re: XPath as CSS-selectors?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 19 Jun 2003 13:44:47 -0500
Message-ID: <3EF2049F.40408@mit.edu>
To: www-style Mailing List <www-style@w3.org>
CC: Asbjørn Ulsberg <asbjorn.ulsberg@nrk.no>

Asbjørn Ulsberg wrote:
>>CSS Selectors are currently carefully designed for
>>performance. XPath is not.
> Well, this is an implementation issue, and not caused by the
> design tiself.. Or?

It's caused by the design, though can be somewhat mitigated by 
implementation.   As of CSS2, a node can only affect the  styling of its 
descendants.  That is, if a node's attribute changes, eg, the styles of 
its descendants will need to be reresolved but the styles of all other 
elements in the DOM tree will be unaffected as a matter of design of 
CSS2 selectors.

In CSS3, this constraint is weakened a bit.  With CSS3 Selectors, a node 
affects the styling of all descendants of its parent (since it can 
affect the styling of siblings and their descendants via the '+' 
combinator and selectors such as :nth-of-type).  Note that the :matches 
selector in its various forms, which would weaken this constraint even 
further, keeps being not added to CSS Selectors due to concern about 
performance issues...

On the other hand, with XPath any element can affect the styling of any 
other element, as has already been mentioned.  Consider a web page using 
a 'javascript ticker' (quite common) that relies on XPath selectors. 
Since every step of the ticker involves changing the style attribute of 
some element, every step could potentially trigger a reresolve of style 
on every single node in the DOM tree.  Now one can optimize this in some 
ways, eg by keeping around flags that say whether any of the currently 
loaded sheets contains a "bad" selector (one that introduces a 
dependency between the style of a node and the properties of some node 
that is not its sibling or ancestor or sibling of an ancestor).  So 
pages that do _not_ use such selectors could maybe still be reasonably 
fast... but pages that do use them would have abysmally slow response to 
any dynamic changes (every single DOM operation would trigger a full 
style reresolve).

Of course it is precisely having such selectors that is one of the main 
advantages of XPath over CSS Selectors as stated earlier in this thread, 
so eschewing their use makes XPath far less desirable...

> The more, the merrier. Right?

Well, not from a UA implementor standpoint... ;)

> As Chris Lilley mentions, XPath is used in XForms, which is a
> pretty "dynamic environment". Though XPath wasn't necessarily
> designed for use in a dynamic environment, I think it works fine
> with XForms.

Could you please point me to the UA you used to evaluate how well it 
works?  I would very much like to try out XForms.

Received on Thursday, 19 June 2003 14:44:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:07 UTC