W3C home > Mailing lists > Public > www-style@w3.org > July 2005

FW: [selectors] Yet another attempt at trees

From: ben <arcticmac@comcast.net>
Date: Thu, 21 Jul 2005 19:58:57 +0000
Message-Id: <a06200710bf05a916d487@[192.168.11.4]>
To: www-style@w3.org
To Quote:
Possible objection:
How does this help with finding 3rd level headings in the following?

<body>
<h/>
<section>
<h/>
<navigation>
<h/>

It helps somewhat to simplify the task.  Assuming that body, section, and
navigation can occur in any order and that level headings should only be
advanced when they are encountered, it would take 108 different selectors
with existing CSS to specify rules that apply only to third level headings.
(27 of the form S S S h to set the 3rd and greater level headings and 81
more of the form S S S S h to set back the 4th level and higher level
headings to what they were before, assuming that the user doesn't have his
own style rules for h that get clobbered as a result.)  In contrast, it
would take only 10 different selectors of the form
h:ancestors(x,body):ancestors(y,section):ancestors(z,navigation) where
x+y+z are whole numbers adding up to 3 if this selector were available.

Any further simplification would require implementing something analogous
to the oft proposed :matches().  Simpler to leave the door open, as this
proposal does, for :ancestors(3,:matches(body,section,navigation)) to being
someday usable than to try and duplicate the functionality with
:ancestors(3,body,section,navigation) since doing so would make
:ancestors(n,body,section,navigation) have the same functionality as
:matches(body,section,navigation).

------------------------------

An intriguing example, however, I might point out that
1. most things like this would occur inside a standard parent element 
(we'll call it parent here) so you could simply do
parent > body >section > navigation > h {}
and so on mixing up the order of body, section, and navigation until 
you have them all, thus eliminating the need for the other 81 
selectors.
2. while it's not always the case, it would often happen that body, 
section, and navigation can only occur within each other (other than 
the parent element), which would allow you to write this single 
selector for all the rules:
parent > * > * > * > h {}
3. even if #2 is not the case, it requires only an additional three 
selectors to undo the changes for any additional elements, which 
gives you three others that you can set before you come to the total 
of ten selectors required by your proposed tree method.

That is, say we have elements book, chapter, section, paragraph, 
sentence, and navigation which can come nested in any order; and of 
course, we have an h element too.  the three that we want to use for 
third level headers are book, section, and navigation.   All are 
contained in a body element.  The following style rules would suffice 
to do your example:
body > * > * > * > h {whatever special style for third level headers}
body > chapter > * > * > h {back to default style}
body > * > chapter > * > h {back to default style}
body > * > * > chapter > h {back to default style}
body > paragraph > * > * > h {back to default style}
body > * > paragraph > * > h {back to default style}
body > * > * > paragraph > h {back to default style}
body > sentence > * > * > h {back to default style}
body > * > sentence > * > h {back to default style}
body > * > * > sentence > h {back to default style}


SO, I conclude that your example wasn't much good. (although that's 
just cause I like to play devil's advocate)

However, I like your syntax (aside from the fact that it scares me a 
little bit to add even more funky selectors to css),  and some of 
your other examples were good.  (what, for example, if you wanted to 
make a tree alternate background colors in a cycle of three...  next 
to impossible to do in today's css, but with your method it could be 
done.

Aside from that there is a minor problem in that it could well end up 
being one of those things that we'd all really love to see, but never 
gets implemented, despite its presence in the spec...

Anyhow...
Received on Thursday, 28 July 2005 15:19:21 GMT

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