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

Re: New draft: css3-selectors

From: Jeffrey Yasskin <jyasskin@hotmail.com>
Date: Thu, 01 Feb 2001 09:30:17 -0600
To: www-style@w3.org
Message-ID: <F82PmsSVhGOD6gx3lKy00001f29@hotmail.com>
I agree that CSS having its own selection language completely separate from 
XPath and XQuery is not a great idea. However, I don't think that 
intruducing regular expressions will help. Regular expressions will limit 
the development of CSS stylesheets to developers familiar with or willing to 
learn regular expressions.
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
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


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
Received on Thursday, 1 February 2001 10:30:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:08 GMT