W3C home > Mailing lists > Public > www-style@w3.org > March 2016

Re: [selectors] Rewrote grammar in terms of the Value Definition Syntax

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 18 Mar 2016 11:15:34 -0700
Message-ID: <CAAWBYDC4JO5Xv6BdbTEg+xkdswahQuPkHZGHLe1EeFO2R=+mfw@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: www-style list <www-style@w3.org>
On Thu, Mar 17, 2016 at 6:37 PM, Alan Stearns <stearns@adobe.com> wrote:
> On 3/17/16, 5:53 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>As I've been threatening to do for quite some time, I finally rewrote
>>the grammar for Selectors in terms of the CSS Value Definition Syntax,
>>removing the old grammar written in terms of the Appendix G syntax.
>>This is one more step in the effort to remove *all* grammars written
>>against the old Appendix G syntax from CSS, now that CSS is no longer
>>defined in a way that's directly compatible with it.
>>
>>Once auto-generation finishes in a few minutes, you can find it at
>><https://drafts.csswg.org/selectors/#grammar>.  Please review and let
>>me know if you notice any mistakes!
>
> The + combinator, * type-selector, and | ns-prefix character are incorrectly linked to values and units.

Fixed. Bikeshed was a little too eager to auto-link things that
*looked* like grammar modifiers.

> I find it a bit odd that <class-selector> is fully defined here, but <id-selector> refers to <hash-token> from CSS Syntax, which is a link to a list of tokens that doesn’t explain the token’s grammar. I see how the grammar is defined in the tokenization algorithm, but it’s not a simple thing to find from the Selectors link. I’d prefer is Selectors had a way to clearly state what the grammar is without this indirection.

<class-selector> is as "fully defined" as <id-selector> - the
definition of <ident-token> is just as hard to divine as the
definition of <hash-token>.  This is a good argument that I could
clean up Syntax a little, tho.  Unfortunately, I can't succinctly and
correctly define most of the tokens without reproducing the parser -
that's why I currently *don't* try to define them normatively, and
just depend on "whatever makes the parser output these" as the
definition.  I'm not sure how to fix this well without accidentally
suggesting to more casual readers that the definition is something
simple (and incorrect).  (Unfortunately, "casual readers" often
include implementors, particularly if they're new or doing drive-by
fixes and thus are unfamiliar with a lot of CSS stuff.)

~TJ
Received on Friday, 18 March 2016 18:16:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC