Re: Pseudo-element proposal

On Tue, Aug 7, 2012 at 12:03 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> 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.

The problem occurs when the "foo bar" parts become non-trivial.
Repeating them then is much more annoying.

You must also weigh it against the ease of just using an
::nth-pseudo(), even if it's fragile.  If they can instead just write:

foo bar::nth-pseudo(before, 5+n) {
 ...
}

Then you can bet that they will, even though this has bad effects if
someone adds or removes pseudos before the intended group.


>> 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.

The problem isn't one of restriction, it's one of semantics.  Stacking
pseudo-elements like "foo bar::nth-pseudo(before,
5+n)::nth-pseudo(before, 10-n)" looks like it means you're selecting
the first 10 before pseudos inside the bigger-than-5 pseudos of the
bar elements.

Unless we're willing to complete munge together the concept of
pseudo-elements and pseudo-classes, we need something a little
different.


>> 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 ;-)

Yes, of course.

~TJ

Received on Tuesday, 7 August 2012 19:29:40 UTC