W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-values] Automatic parsing of value definitions

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Tue, 17 Jul 2018 08:58:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-405510928-1531817875-sysbot+gh@w3.org>
> [`<feature-type>`] is valid; it's using the extended Value Definition Syntax for rules defined in https://drafts.csswg.org/css-syntax/#rule-defs.

Ah, got it! We did not pay much attention to these rules because we restricted ourselves to properties and descriptors for now. From an automated parsing perspective, it's not entirely clear how to distinguish between the two when parsing a `<pre>` tag. The initial rule starts with an `@`, that's easy, but the remaining rules look like value definitions.

I guess another thing that I'm wondering about is the intended scope of these definitions. For instance, that spec contains two references to `<family-name>`: one in the [definition of `font-family`](https://drafts.csswg.org/css-fonts-4/#propdef-font-family), and one in the [definition of `@font-feature-values`](https://drafts.csswg.org/css-fonts-4/#font-feature-values-syntax). The syntax of the first one is [defined in prose](https://drafts.csswg.org/css-fonts-4/#family-name-syntax). The syntax of the second one is defined in the at-rule definition. Automated tools are essentially dumb and will happily think that the second `<family-name>` definition applies to both cases. Given that the second definition links back to the first, I suspect that Bikeshed thinks equally. Using the same name in both situations seems totally fine here, but then it's a bit strange to apply different parsing rules depending on how you reach that definition. Anyway, that example is totally moot in practice, because the outcome of both parsing rules is exactly the same, I'm just trying to keep the grammar clear and simple so that tools can remain as dumb as possible.

> I think we should encourage using =, yeah. While technically not necessary for linking purposes (Bikeshed takes care of things already), it makes things a bit clearer, I think.

OK. FWIW, we created a [list of "missing" rules](https://github.com/tidoust/reffy/blob/master/src/specs/missing-css-rules.json) with possible values for definitions that we could not extract automatically. Time permitting, we'll report these to individual specs or prepare appropriate PR.

> Ranges, yeah. Regexes unlikely to show up - what's the use-case for them?

I guess the use cases that we had in mind for regexes were:
1. the definitions of tokens such as `<ident-token>` to complete the [railroad diagrams](https://drafts.csswg.org/css-syntax/#token-diagrams).
2. the definitions of a few constructs that currently use prose to constrain values such as [`<custom-property-name>`](https://drafts.csswg.org/css-variables/#typedef-custom-property-name), [`<hex-color>`](https://drafts.csswg.org/css-color/#typedef-hex-color) or [`<signed-integed>`](https://drafts.csswg.org/css-syntax-3/#typedef-signed-integer).

That may not be compelling enough use cases to warrant the introduction of regexes.

GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2921#issuecomment-405510928 using your GitHub account
Received on Tuesday, 17 July 2018 08:58:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 17 July 2018 08:58:13 UTC