- From: Chris Lilley <chris@w3.org>
- Date: Wed, 18 Jun 2003 20:57:37 +0200
- To: www-style@w3.org, Ian Hickson <ian@hixie.ch>
- CC: (wrong string) ørn Ulsberg <asbjorn.ulsberg@nrk.no>
On Wednesday, June 18, 2003, 6:34:00 PM, Ian wrote: IH> On Wed, 18 Jun 2003, [iso-8859-1] Asbjørn Ulsberg wrote: >> >> What I notice, clearer than with CSS1 and 2, is that the CSS selectors >> just is a way of selecting nodes, exactly like XPath. [big snip as Ian makes lots of good points] >> 4. It is imho more powerful than CSS-selectors. IH> It was not designed for use in dynamic environments, which is a IH> requirement for the selecting language used in CSS. For example, it would be trivial to make an XPath selector that would block all CSS rendering by making the styling of the first element be dependent on an attribute on the last element. And Xpath does not have the equivalent of pseudo-elements or pseudo-classes. It is not possible to make an XPath that selects the first line in a paragraph, or unvisited links, for example. Ian, in general, I agree that XPath was designed more for a batch-oriented, one-shot transformation process like XSLT rather than for a continuously evaluated dynamic system like CSS. What I wonder though is whether you - or anyone on this list - has made a more detailed evaluation and comparison of Xpath and of CSS Selectors I terms of power, implementation efficiency, and problems that would occur in dynamic as opposed to static usage. Not necessarily in the context of a selectors replacement, either. For example, XForms uses XPath expressions to bind abstract widgets to portions of the model. Since that is a dynamic process, it would be interesting to get a more detailed sense of what the pitfalls are. -- Chris mailto:chris@w3.org
Received on Wednesday, 18 June 2003 14:58:06 UTC