RE: [selectors5] Proposal for a pseudo combinator


[Tab Atkins Jr.:]
> 
> Right now, pseudo-elements are selected by appending a "::foo" to the end
> of a compound selector, as if it were any other simple selector.
> This syntax dates back from CSS1, when the only pseudo-elements
> were :first-line and :first-letter, which are heavily restricted in what
> properties they can take.  In many ways, these can be considered to not be
> elements at all, but rather simply a special way to apply properties to a
> subset of text.
> 
> This changed with CSS2 and its introduction of ::before and ::after -
> these were completely unrestricted in the properties they could accept,
> and are generally identical to 'real' elements.  However, for consistency
> we stuck with the CSS1 syntax for pseudo-elements, only changing from a
> single colon to a double colon.
> 
> This syntax has some drawbacks.  For one, it's unclear from the syntax
> that what you're actually selecting is a brand new element - this is
> usually indicated by the use of a combinator, but :: doesn't have the
> qualities of a combinator.
> 
> 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). WebKit
already allowed this for proprietary control pseudo-elements. IE10 currently
allows this for a number of similar pseudo-elements [1]. 

[1] http://msdn.microsoft.com/en-us/library/windows/apps/hh465740.aspx




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

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.

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

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. 

> 
> This would allow selectors like "p :: before:hover", yay!  If we in the
> future relax the restriction of "one pseudo-element per selector", a
> selector like "p :: before :: before" seems easier to read than
> "p::before::before".
> 
> One further change is needed to give this proposal complete backwards-
> compatibility - allow sequences of multiple combinators, which imply a
> universal selector between them.  Then, selectors like "p > ::before"
> would still be valid *and* would match the exact same elements as today -
> it would be identical to the selector "p > * ::
> before".

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.

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


[2] http://www.impressivewebs.com/css-the-bad-parts/


> 
> ~TJ
>

Received on Saturday, 7 April 2012 02:19:33 UTC