- From: ben <arcticmac@comcast.net>
- Date: Thu, 21 Jul 2005 19:58:57 +0000
- To: www-style@w3.org
- Message-Id: <a06200710bf05a916d487@[192.168.11.4]>
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 UTC