Re: [selectors4][css-syntax] Pseudo-elements vs. combinators

On Feb 4, 2014 10:58 PM, "Sylvain Galineau" <galineau@adobe.com> wrote:
>
> A recurring debate in the WG - both last week in Seattle and at previous
meetings - pitted new combinators vs. pseudo-elements. The former are
generally deemed too cryptic as well as unsustainable: there are only so
many non-alphanumeric characters left on our keyboard, yet enough of them
that adding more just makes things more confusing. As a result, I have
heard a few times: "We should stop adding combinators and use
pseudo-elements instead".
>
> That seems a little odd to me, as it means hacking the pseudo-element
syntax for the purpose of describing things that aren't really
pseudo-elements i.e. it feels like solving one problem by creating another
different one. While one or two combinator characters may be hard to read
or remember, what comes after a combinator is generally well-understood and
unconstrained by pseudo-element syntax. It also deals with the concern that
having things that look like pseudo-elements but aren't is just moving
confusion around.
>
> One suggestion would be to allow future combinators to be mnemonics or
even words; we'd presumably need to agree on a common prefix for them to
disambiguate them for elements.
>
> So just like
>
> ::<name> indicates a pseudo-element,
> :<name> indicates a pseudo-class,
>
> we'd have
>
> <combinator-prefix><name> indicate a combinator.
>
> The bikeshedding, of course, resides in choosing <combinator-prefix>. But
before even getting there, I was wondering what'd be daft about this?

Does it require changes to the forward compatible parsing rules?  I'm not
saying it does or doesn't or that there is no reason to ever change it -
just asking our experts..