- From: Jeffrey Yasskin <jyasskin@hotmail.com>
- Date: Thu, 01 Feb 2001 09:30:17 -0600
- To: www-style@w3.org
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 UTC