Re: [selectors5] Proposal for a pseudo combinator

On Fri, Apr 6, 2012 at 7:18 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
> [Tab Atkins Jr.:]
>> For two, the syntax forces the pseudo-element to be at the end of the
>> selector, which prevents us from filtering based on qualities of the
>> pseudo-element, such as wanting to style it differently when hovered.
>> (This is another legacy from CSS1, where there were no pseudo-classes that
>> could possibly apply to pseudo-elements.)
>
> You can't in Level 3 and earlier; Selectors Level 4 allows pseudo-classes
> on pseudo-elements (see last paragraph of 3.4 Pseudo-elements).

!!!  That's new.  I had completely missed that.


>> For three, this prevents us from implying more structure inside of the
>> pseudo-element.  For example, if a ::before is set to "display:
>> list-item;", it will generate a list marker, but the syntax prevents us
>> from actually *selecting* the ::marker pseudo that's inside of it.
>> In the Web Components effort, one potential method for selecting into the
>> shadow tree is using a ::shadow pseudo-element that matches the root of
>> the shadow tree attached to an element, but the current syntax prevents us
>> from digging further into the shadow DOM from there.
>
> I think there is a requirement here though I'm not sure I follow you: yes, I
> believe we'll need a way to select into the shadow tree but I'm not sure why
> a pseudo-element is the only or better option to represent the shadow root.
> Given some of the shortcomings you describe one could also argue shadow tree
> selection may be better served by a combinator that delimits shadow tree
> selectors from what's 'above' them.

Yes, I'm not certain it's the best way to select into the shadow tree,
but it's a possible way, and this would make it more attractive.

The shadow tree thing is a very small part of this argument, though.
More important is the reason presented earlier in the paragraph, where
pseudo-elements can have their own pseudo-elements, like
"::before::marker" or (if we go the pseudo-element route)
"::after::region()".  If we ever adopt something like what used to be
in the Content draft, we'll also have "::before::after::outside".  ^_^

When each of these can have pseudo-classes applied to them, so that we
have to redefine "compound selector" from "a set of simple selectors,
possibly with a pseudo-element at the end" to "a sequence of sets of
simple selectors, separated by pseudo-elements", it starts becoming
unclear what the difference is between that and "complex selector",
which is just "a sequence of sets of simple selectors, separated by
combinators".  By allowing pseudo-elements to have pseudo-classes or
pseudo-elements, you're implicitly stating that there's a separation
there very similar to what combinators normally provide.


> In other words, once we've established that the shadow root *must* be a
> pseudo-element then you're on firmer ground. As things are, it sounds like
> you're simply assuming it ('one potential method for selecting into the shadow
> tree...') and then, voila, we need a combinator.

As I said above, the shadow-root thing was a tiny bit of my overall
argument.  Don't focus on it too much if you don't find it convincing.


>> For all of these reasons, I propose that in Selectors 5 we reify pseudo-
>> elements properly, making them real elements (from the perspective of
>> Selectors) that are targeted with a "pseudo"
>> combinator.  I propose this combinator be the double-colon we currently
>> use to indicate pseudo-elements.
>
> This is the bit that lost me somewhat. If I need a special combinator to
> target them, how are they 'real' elements? They're still special; all you're
> doing is making a lot more stuff after them valid - which, granted, is the point -
> by adding spaces around this apparently confusing :: stuff.

They're real elements that simply don't live in the "normal" children
subtree of an element.  The pseudo combinator shifts us into the
pseudo-tree, just like the child combinator shifts us into the
children.

> Incidentally, I have a hard time believing the people who are confused by
> double-colon pseudos vs. single-colon pseudo-classes will have a 'aha!' moment
> when the dreaded double-colon has spaces around it. If you can understand that
> then I am missing what is hard about what we have now. I'm actually more worried
> about confusing all the people who do understand it.

I think you're downplaying the extent of the confusion caused by
pseudo-elements looking like a simple selector, and in particular,
looking like a pseudo-class (since many people still use the
single-colon form).  I just had to disabuse some Motorola engineers of
this confusion in a webkit bug a few days ago.

The spaces around combinators are an intuitive indication that you're
now talking about a new thing, which I believe would help many
people's mental model.


> As of now I have a hard time seeing the benefits being worth the work.
> Yes, the syntax and concept confuses some people. But it also arguably
> works for many others. See this recent post on the 'bad parts' of CSS[2]:
> it only mentions the issue in terms of "Why did you add another colon?
> Who cares?" i.e. don't change things for the sake of changing them. I
> don't know if its coming last is intentional but it does seem one of the
> least painful items on the list overall.

The actual complaint in that article is "IE8 still only supports the
single-colon, so we're stuck with it for years to come." They don't
actually complain about the double-colon itself (and in another post
linked from that section, they do reason that the double-colon form
allows for easier maintenance, as it's easier to distinguish).

I don't think I'm changing things for the sake of changing.  My
suggested change does, imo, make current selectors very slightly
easier to read, but it's meant to help selectors stay readable as we
evolve them in the ways we're already planning to.

> I wouldn't discourage you from digging further into this but I don't
> think you've identified enough value to justify the change yet.
>
> And the [selectors5] subject header doesn't suggest much urgency either,
> fwiw....:)

That was the point.  ^_^  It's not urgent, but I think it helps solve
real readability problems, and believe we should consider this before
we extend pseudo-elements any further.

~TJ

Received on Saturday, 7 April 2012 16:15:47 UTC