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

Re: New draft: css3-selectors

From: Patricia Ballad <PBALLAD@tuc.com>
Date: Thu, 01 Feb 2001 10:38:35 -0600
Message-Id: <sa793cb2.033@tu_asynch_1.tuc.com>
To: <www-style@w3.org>
Just a quick note - Sure, giving all of us developers one more thing to learn isn't necessarily going to make anybody popular, but it seems self-defeating to cling to an old standby when developing something new would make more sense - If we weren't willing to learn a new language if the need arose, we'd all be sitting around writing our web applications in {SHUDDER} Assembler......<insert standard disclaimer to all those Assembler fans out there>


>>> "Jeffrey Yasskin" <jyasskin@hotmail.com> 9:30:57 AM Thursday, February 01, 2001 >>>
W3C selectors are very powerful, but they duplicate a lot of the 
functionality of the XPath selectors and are not as powerful. I would rather 
see XPath selectors be supported in CSS. Then the W3C could spend twice the 
time refining XPath, developers would only have to learn one selection 
language, and browser makers could reuse code.
This has all of the advantages of your proposal without forcing web 
designers to learn very complicated regular expression rules. However, it 
would break forwards compatability and would make developers who only use 
CSS learn a new language.
What do you think?

Jeffrey Yasskin, MCSD

----Original Message Follows----
From: Biep Durieux <bdurieux@baan.com>
To: "'www-style@w3.org'" <www-style@w3.org>
Subject: Re: New draft: css3-selectors
Date: Thu, 1 Feb 2001 06:43:43 -0500 (EST)

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

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>

(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;

(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

Get your FREE download of MSN Explorer at http://explorer.msn.com 
Received on Thursday, 1 February 2001 11:39:27 UTC

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