Re: [selectors5] Proposal for a pseudo combinator

On Thu, Apr 5, 2012 at 4:13 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/05/2012 03:44 PM, Tab Atkins Jr. wrote:
>> 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.
>
> I don't see any benefit to solving this.

The benefit is better readability.  It's minor, but it's real.  I
cannot tell you how many times I've had to teach someone that
pseudo-classes and pseudo-elements are completely different things,
because their current syntax makes them seem like the same thing.  For
example, I had to do it yesterday in a webkit bug.


>> 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.)
>
> This is a restriction that we can relax.

Yes, but then readability and understandability continues to decline.

I mean, we'll have to change the meaning of "compound selector",
because "p::before:hover" is *not* the same thing as
"p:hover::before".  In all other circumstances you can arbitrarily
re-order simple selectors within a compound selector (except that
tagname selectors must come first, for trivial syntax reasons).

Similarly, what about something like "p::before:hover::marker"?
That's difficult just for my eyes to parse.  ^_^  Redone as "p ::
before:hover :: marker", it's immediately much more understandable.

The only reason current pseudo-element syntax isn't horrible is
because of the syntax restrictions we have that prevent you from doing
anything interesting.

~TJ

Received on Thursday, 5 April 2012 23:44:59 UTC