W3C home > Mailing lists > Public > www-style@w3.org > February 2014

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

From: Sylvain Galineau <galineau@adobe.com>
Date: Wed, 5 Feb 2014 03:55:54 +0000
To: "<www-style@w3.org>" <www-style@w3.org>
CC: Tab Atkins Jr. <jackalmage@gmail.com>
Message-ID: <49935D08-3F6B-4154-8533-606F1C32886A@adobe.com>
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?
Received on Wednesday, 5 February 2014 03:56:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:18 UTC