[csswg-drafts] [selectors-4] Augment the grammar to unambigously encode handling of white-space? (#10940)

amn has just created a new issue for https://github.com/w3c/csswg-drafts:

== [selectors-4] Augment the grammar to unambigously encode handling of white-space? ==
I've now read the useful prior, since closed issue at https://github.com/w3c/csswg-drafts/issues/7027 which touches upon similar subject.

I must say it helps greatly that the selectors grammar _is_ defined in terms of [a more or less] formal notation (not saying it's informal since Values & Units specifies the notation elements pretty well), but the parable(s) following it that clarify handling of white-space throw me off, I must admit. By that I mean that it's not made very clear where to allow white-space in the parser and where not to.

In the aforementioned related issue, @tabatkins says, quoting, whitespace is allowed between _any_ two grammar productions -- is this still the case [with the Editor's Draft] edition of the Selectors 4 specification? I think it wouldn't hurt to start the parable(s) following the grammar proper, with a sentence that says so.

As for the issue I wanted to share -- would it not make sense -- _if_ we (you) attempt to encode handling of white-space _into_ the grammar, to eliminate interpretation ambiguity? The white-space production is defined in the Syntax module [Level 3, Editor's Draft] spec.: https://www.w3.org/TR/css-syntax/#whitespace, after all -- why not build upon that and insert as required into the Selectors grammar?

Specifically, what about replacing the `combinator?` part (which currently requires the [less formal] clarification on omission of the `?`-subject production, following the grammar), with e.g. `[ combinator | whitespace ]`? (let's for the sake of the example assume a rule equivalent to `<whitespace> = '\n' | '\t' | ' '`)

...and in similar fashion approach re-writing of the informal part(s) following the grammar, to be specified with the grammar.

This isn't critical, admittedly, but for me personally it makes a hard choice deciding whether I _could_ use a parser generator (taking a grammar file as input) or whether I _must_ resort to hand-written parser (since quality of a machine-generated parser, e.g. from grammar, would stand and fall on the quality of the grammar being its chief input).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10940 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 24 September 2024 13:03:51 UTC