W3C home > Mailing lists > Public > www-style@w3.org > March 2011

RE: [css3-selectors] Allowing pseudo-classes on pseudo-elements

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Mon, 14 Mar 2011 00:07:15 +0000
To: Bert Bos <bert@w3.org>, W3C style mailing list mailing list <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AB8D46A@TK5EX14MBXC113.redmond.corp.microsoft.com>


[Bert Bos:]
> Subject: Re: [css3-selectors] Allowing pseudo-classes on pseudo-elements
> 
> On Mar 10, 2011, at 01:34, Sylvain Galineau wrote:
> 
> > Current selector syntax does not allow a pseudo-class to qualify a
> pseudo-element i.e. E::first-line:hover will not match when the first line
> of E is hovered.
> [...]
> > I wanted to inquire as to the reasons for this limitation, as well as
> the possibility of lifting it in a future version of CSS Selectors.
> 
> It is simply that it doesn't make sense to apply a pseudo-classes to a
> pseudo-element for any of the pseudo-classes and pseudo-elements currently
> defined. It's not impossible that certain future pseudo-classes and -
> elements *can* be combined. (On the other hand, given that we have so many
> already that cannot be combined, maybe we discovered a pattern that is
> worth keeping, if only for usability reasons?)

Why doesn't it make sense to be able to apply a ::hover rule on ::first-line,
::before or ::after but it's OK to do so to explicit markup that achieves
the exact same results as these constructs ?

> 
> E.g., the purpose of ':active', ':hover', ':focus', ':visited' and ':link'
> is to show that something is happening, going to happen, could happen, or
> has recently happened. But, with a pseudo-element, nothing is ever going
> to happen, because it can have neither an HREF attribute nor any form-
> related attributes, nor indeed any other semantics, because such semantics
> can only be in the source document, not in CSS.

Same as above; all the pseudo-elements in CSS2.1 can most certainly be clicked
or hovered. I grant that :focus, :visited and :link don't make much sense but
they're not terribly useful on other element types either; yet we have them.
 
> Similarly, ':nth-child' and its cousins make no sense for pseudo-elements,
> because pseudo-elements, by definition, aren't in the document tree.

Fine. Although, conceptually, I don't see why a pseudo-element could not have
children of its own; they may not be selectable from the document tree (the
root element) but you could access them through the pseudo-element itself.
Some implementations already sort of expose this (see 
http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/)

> Even among the pseudo-classes and pseudo-elements of css3-ui there doesn't
> seem to be any useful pair. At best such a pair would simply have the same
> meaning as with the pseudo-class *before* the pseudo-element.

None of this explains why pseudo-classes should not apply to any/all pseudo-element,
whether the upcoming ::grid-cell or simply ::first-line. That some combinations do
not make sense does not justify not allowing those that do. The :visited, :link
or :focus pseudo-classes are of limited practical value on many element types but
that doesn't prevent CSS from allowing them for all simple selectors.

> 
> > [1] http://dev.w3.org/csswg/css3-grid-align/
> > [2] http://dev.w3.org/csswg/css3-ui/#pseudo-elements
> > [3] http://www.webkit.org/blog/363/styling-scrollbars/
> 
> 
> 
> Bert
> --
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
> 
> 
Received on Monday, 14 March 2011 00:07:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT