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

> Now, for the Selectors grammar to simply omit their presence in productions, instead opting for informally defining how these tokens are to be dealt with by parsers -- in prose, in my opinion does a real disservice to parser writers?

They're omitted *by definition* - the grammar that we use in CSS specs is *defined* as applying to tokens and component values, as produced by the parser defined in CSS Syntax, and then further details are defined in Values & Units (or, in some cases, the Syntax spec as well). One of those details in V&U's definition is that whitespace tokens are *implicitly allowed* between any two tokens but *never required*, unless prose specifically requires or forbids them in a particular location.

This rule results in grammars that are dramatically easier to read (and write), as we don't have to clutter grammar definitions with technical details of whitespace placement. Basically, every single pair of tokens in every single grammar, save the tiny handful of locations that require/forbid whitespace somewhere, would contain a `<ws>?` term between them. That sort of repetition helps no-one; it makes almost all grammars harder to read, and makes it harder to spot when there *is* a special behavior, as it would only be indicated by either the lack of `?` (for required) or the lack of the token altogether (for forbidden).

And I know from experience (both personal, and observing other grammars that do explicitly indicate almost-always-optional whitespace) that it's easy to accidentally screw up a detail of this, and accidentally forbid or require whitespace in a location where that isn't intended. It would be difficult to tell if this *was* an accident or not; you'd want to provide accompanying prose repeating the requirement/restriction *anyway* to make it clear when it was intended.

So the end result is that you'd have more cluttered, difficult-to-read-and-write grammars, where it's easy to make mistakes and hard to spot those mistakes, *and* still have the prose descriptions of requirements/restrictions.

In theory we could have special productions that *only* indicate the requirement or restriction of whitespace, and use those *instead of* prose descriptions when it happens. For example, we moved simple numeric range restrictions into the grammar (like `<length [0, 100px]>`) when they were previously only indicated in prose. So far the number of such requirements/restrictions are so low that it hasn't proven necessary.

Note that it will *always* be the case that some grammar restrictions are expressed in prose rather than by complicating the grammar syntax. As I said earlier, we optimize for understandability, not machine-handling; the specs are written and read by humans. If your hope is that you could compile an "all of CSS" grammar and just throw that at a parser generator, you will unfortunately be disappointed.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10940#issuecomment-2377916470 using your GitHub account


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

Received on Thursday, 26 September 2024 20:53:01 UTC