W3C home > Mailing lists > Public > www-style@w3.org > August 2006

Selector for parent/predecessor?

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Sat, 19 Aug 2006 10:53:18 +0200
Message-ID: <cb7bb73a0608190153v7fcdbeew729b0e9996f4f1b1@mail.gmail.com>
To: www-style@w3.org

Hello all,

in my limited HTML authoring experience I've come across a few
situations in which I would have liked to have the possibility to
change the style of an element depending on whether it was the
/parent/ (or more in general an ancestor) of another element, or to
select an element because it was /followed/ by a particular sibling.

In other wors, situations where something like E + F or E > F would
used to select E instead of F (of course with a different syntax).

Admittedly, these situations usually occur where pages aren't
perfectly designed (a typical situation is blog platforms where the
user can prepare the template for the web pages as he wishes, but the
platform also injects some extra HTML).

There are however some particular situations where it makes sense also
for perfectly legitimate situations. For example, consider a complex
web page with multiple sets of radio buttons: it should be possible to
style the container of a set of radio buttons where no radio button is
checked in a different way, as a reminder that the set still has to be
operated by the user. Similarly, when the user must enable at least
one but no more than n checkboxes.

Say for example that the syntax for selecting the parent is F < E
(select an element E that has a child F): then one could use

form { ... }

for all 'wrong' forms, and then

input[type="radio"]:checked < form {...}

to select a form with a checked radiobutton, etc. And if this syntax
might be allowed in a :not() selector it would be even better

input[type="radio"] < form:not(input[type="radio"]:checked < form) { ... }

A similar argument could be made for "predecessor" selectors: one may
want to style paragraphs in a certain way, but in a different way when
they are followed by tables or whatever.

Any comments on such a proposal?

Giuseppe "Oblomov" Bilotta
Received on Sunday, 20 August 2006 02:13:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:25 UTC