W3C home > Mailing lists > Public > www-style@w3.org > February 2001

Re: CSS3 module: W3C selectors

From: Sampo Syreeni <decoy@iki.fi>
Date: Sun, 4 Feb 2001 12:35:08 +0200 (EET)
To: Ian Hickson <ian@hixie.ch>
cc: <www-style@w3.org>
Message-ID: <Pine.SOL.4.30.0102041208430.14544-100000@kruuna.Helsinki.FI>
On Sat, 3 Feb 2001, Ian Hickson wrote:

>Wrong question. The better question would be "Why is XPath selector syntax
>such a departure from W3C selectors?".

That much is in the evidence. But then one must question whether W3C have
sufficient strength, compared to the newer XPath syntax. For instance,
getting the behavior of alternate normal/italic styles for an arbitrarily
deeply nested set of elements (say a dfn>em>em... tree) doesn't happen with
W3C selectors whereas with XPath it would be trivial.

Of course, changing CSS to support XPath, or indeed anything but some
extension of its current selectors, would be a major undertaking and the
result would most likely be highly unaesthetic. XPath even has the
specific problem of being rather an overkill for simple selection of
elements - it was designed as a general expression language, not simply a
one for selecting elements. Hence XPath expressions that can evaluate to
things other than node sets, ones requiring lookeahead (e.g. p[child::img],
which of course would mandate a complete rewrite of any serial CSS
processor) and the fact that, unlike with W3C selectors, there has been no
need to assign specificities to XPath selectors. The last part is to me the
most troubling because CSS really needs selector specificities and it is
not at all clear how one would go about assigning a specificity to a
complicated XPath expression.

That being said, I have to agree that the W3C selector draft does suffer
from syntactic bloat. The large number of new pseudo-classes alone is enough
to make the grammar inelegant. I think perhaps REs or other similar
extensions should be considered - if properly implemented, the resulting
constructs need not be visible to someone who does not understand them or
wish to use them. Plus, REs can be evaluated in a highly efficient fashion
(linear time, no lookahead) and can be made to work for textual content as

Sampo Syreeni <decoy@iki.fi>, aka decoy, student/math/Helsinki university
Received on Sunday, 4 February 2001 05:35:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:56 UTC