Re: New draft: css3-selectors

While on a local level I like the work done, I an getting more and more
negative about the overall direction of the CSS activities.  As I already
voiced somewhat timidly in
http://lists.w3.org/Archives/Public/www-style/2001Jan/0060.html, I think CSS
is heading in the wrong direction, and rapidly turning into a desultory
sprawling language, with a huge dictionary to compensate for a lack of
grammar.

Is there any reason not to include a pattern language into CSS (say,
something like the regexp language used in Unix applications), and use that
to reduce the number of selectors?

(Please don't look at the specifics of the examples given here.  I simply
took the JavaScript regexp language and extended it with an exclamation
point to match the current element, and with tag brackets to match elements.
This does not do justice to the hierarchical nature of XML elements.  A
standards committee could no doubt come up with something cleaner, more
pleasing to the eye, and more intuitive to use..)

E[foo="bar"]		--> E[foo~/^bar$/]		/* or:
E[foo~/^bar$/i], for case insensitive matches */
E[foo~"bar"]		--> E[foo~/\bbar\b/]
E[foo^="bar"]		--> E[foo~/^bar/]
E[foo$="bar"]		--> E[foo~/bar$/]
E[foo*="bar"]		--> E[foo~/bar/]
E[lang|="en"]		--> E[lang~/^en/]
E:nth-child(n)		--> E:child(/^.{n-1}!/)		/* ! indicates the
child to be matched */
E:nth-last-child(n)	--> E:child(/(.).{n-1}$/)
E:nth-of-type(n)		--> E:child(/^([^<E>]*<E>){n-1}[^<E>]*!/)
/* admittedly less beautiful */
E:nth-last-of-type(n)	--> E:child(/!([^<E>]*<E>){n-1}[^<E>]*$/)
/* idem */
E:first-child		--> E:child(/^(.)/)
E:last-child		--> E:child(/(.)$/)
E:first-of-type		--> E:child(/^[^<E>]*!/)
E:last-of-type		--> E:child(/![^<E>]*$/)
E:only-child		--> E:child(/^!$/)
E:only-of-type		--> E:child(/^[^<E>]*![^<E>]*$/)
E:empty			--> E:parent(/^$/)		/* allows lots of
other child patterns of this parent */
E:contains("foo")		--> E:child(/<text[value~/foo/]>/)
E:first-letter		--> E > text:child([value~/^!/])
E#myid			--> E[id~/^myid$/]
E:not(s)			--> E:parent(/^[^!]*[^<s>][^!]*$/)
/* again not so beautiful */

If one is willing to break backward compatibility, an in my opinion nicer
solution is possible, namely abstracting the XML into a pattern and
enriching that with matching operators such as the Kleene star. (Again: with
some careful designing, a much clearer language could be developed):

E[foo]			--> <E foo>
E[foo="bar"]		--> <E foo=bar />				/*
Equivalent to <!E foo=/^bar$/ /> */
E[foo~"bar"]		--> <E foo=/\bbar\b/ />
E[foo^="bar"]		--> <E foo=/^bar/ />
E[foo$="bar"]		--> <E foo=/bar$/ />
E[foo*="bar"]		--> <E foo=/bar/ />
E[lang|="en"]		--> <E lang=/^en/ />
E:nth-child(n)		--> <> .{n-1} <!E> .* </>		/* spaces
have no meaning at the element level *.
E:nth-last-child(n)	--> <> .* <!E> .{n-1} </>
E:nth-of-type(n)		--> <> (<^E/>* <E/>){n-1} <^E/>* <!E> .*
</.>
E:nth-last-of-type(n)	--> <> .* <!E> (<^E/>* <E/>){n-1} <^E/>* </.>
E:first-child		--> <> <!E/> .* </>			/* ANY first
child would be <> ! .* </.> */
E:last-child		--> <> .* ! </>
E:first-of-type		--> <> <^E/>* <!E> .* </>
E:last-of-type		--> <> .* <!E> <^E/>* </>
E:only-child		--> <> <!E/> </>
E:only-of-type		--> <> <^E/>* <!E> <^E/>* </>
E:empty			--> <E></E>
E:link			--> <E href=/./ />			/* URL of at
least one character */
E:checked			--> <E checked>				/*
etc. */
E:contains("foo")		--> <E> <text value=/foo/> </E>
E#myid			--> <E id=myid />
E > F				--> <E> .* <!F> .* </E>

Advantages:
(1) It simplifies the language specification (one can reconstruct instead of
having to remember the exact syntax);
(2) The possibilities are not limited to what the standard developers did
think of: the language is infinitely richer.
    For instance, I can match:
    - an element with exactly three children: <> . . . </>
    - a link to my own website: <A href=/http:\/\/www.biep.org/ />
    - an element of the same type as its father: <(.)> .* <\1> .* </>
(3) It imposes uniformity;
(4) It allows for smaller browsers because of code re-use;
(5) Since less code is used more often, browser bugs will show up earlier,
even for "esoteric" features;

Disadvantages:
(1) Unless the pattern language is carefully chosen, some common patterns
may be ugly or unwieldy.

Please, don't let CSS deteriorate into bloatware!

J. A. Durieux
mailto:BDurieux@baan.com
http://www.biep.org

Received on Thursday, 1 February 2001 07:52:09 UTC