- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 19 Jun 2003 13:44:47 -0500
- 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. -Boris
Received on Thursday, 19 June 2003 14:44:51 UTC