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

Re: Pseudo-element proposal

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Tue, 07 Aug 2012 21:03:21 +0200
Message-ID: <50216679.6070303@disruptive-innovations.com>
To: www-style@w3.org
Le 07/08/12 20:21, Tab Atkins Jr. a écrit :

> 1) If you're creating multiple similar pseudos, you'll obviously want
> to fold the repeated styles into a single rule.  You *could* do it by
> chaining selectors with a comma (e.g. "foo bar::before(5), foo
> bar::before(6), foo bar::before(7)"), but I suspect that people will
> end up wanting to instead use ::nth-pseudo for it.  Unfortunately,
> because of the index/ordinal mismatch, this is fragile to pseudos
> being inserted before them.
> Maybe this could be relegated to ::matches() or something, like "foo
> bar:matches(::before(5), ::before(6), ::before(7))", I dunno.

Hmmm. I don't really like it, and you forget that web authors use
line feeds to present things in a more maintainable way:

   foo bar::before(5),
   foo bar::before(6) {
     ..
   }

and that's very readable and maintainable.

> 2) The other nth-* things are all pseudoclasses, which is useful for
> some use-cases because you can stack them.  For example, to select the
> 7th through 10th children of an element, you can do "foo:nth-child(7 +
> n):nth-child(10 - n)".  You can't stack the ::nth-pseudo things,
> though, because they're pseudo-elements.  This is somewhat
> unfortunate.  This doesn't seem easily addressible without reifying
> pseudo-elements in Selectors, so that they're independent "elements"
> that can accept other simple selectors.

Wait. You can't stack pseudo-elts *now*. I envision future changes in
pseudo-elements that will become almost certainly necessary:

1. nested pseudo-elements at the end of the same simple selector, we
    already discussed this at least once

2. being able to select real content "placed" into a pseudo-element
    by a mechanism like grids or regions; we do that right now using
    at-rules but I don't see why we could not use an extended selectors
    syntax instead of at-rules. It will be more readable and easier to
    deal with.

I don't see the fact :nth-* is currently used by pseudo-classes only
as a reason to restrict it to them.

> Related to (2), it would be unfortunate if we continued to be unable
> to use things like :hover on pseudos.  I suggest a general solution to
> this problem - recast the :: as a combinator, shifting into the
> element's pseudo-tree.  I've explored this before, and there are a few
> wrinkles because of the way that pseudo-element syntax generally
> interacts with other selectors (for example, "::before" is a valid
> selector, but if :: is recast this then becomes a selector starting
> with a combinator, which is a no-no), so we'll need some exceptions to
> accommodate today's syntax.
>
> Once you have that, though, this becomes easier.  You can throw away
> ::nth-pseudo entirely, and replace it with the existing :nth-of-type()
> selector, like "foo :: before:nth-of-type(even)" to select all the
> even "before" pseudos.  (Or, omitting unnecessary whitespace,
> "foo::before:nth-of-type(even)", which looks like the natural
> extenstion of today's syntax.)  Then "foo::before:hover" is nice and
> easy!

That's an interesting idea but I guess it requires much more input
before we can comment on it. It's not for tomorrow, as we say in
french ;-)

> I haven't yet reviewed the API parts in any detail.

Thanks for your comments!

</Daniel>
Received on Tuesday, 7 August 2012 19:03:50 GMT

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