Context for this issue is that @dontcallmedom and I spent some time integrating CSS specs in the list of specs crawled by Reffy. Our goal was to extract and parse value definitions for CSS properties and descriptors from all CSS specs, first step that could then perhaps be used to detect potential anomalies, automate the creation of parsing tests, or create tools that list CSS properties (apart from the detection of a few anomalies which led to the issues I reported yesterday and today on individual specs, we haven't had time yet to look into using the result of this parsing).
This exercise was also meant as an occasion for us to take a deeper look at how CSS specs are written. It is quite possible that we misunderstood a few things, we're much more familiar with API specs in practice. Also, as opposed to API specs where the automatic extraction of IDL content allows to create tests, and actual stubs for implementation, the automatic extraction and parsing of value definitions of CSS properties may perhaps not be seen as an interesting goal or a priority, because that does not trigger major interop issues in practice.
That being said, taking for granted that the goal of the Value Definition Syntax is to ease the automatic parsing of values, we noted a few potential issues:
Keyword values do not allow for some of the values actually used in specs. The syntax defines keyword values as identifiers which conform to the <ident-token> grammar. Unless we read that definition incorrectly, this does not allow keywords to start with a digit or with an @. Some values need that such as glyph-orientation-vertical, font-weight (although value was replaced by <number> in Level 4), or <feature-type> (e.g. @stylistic).
The syntax does not describe the use of = to define expansion rules of non-terminals. Most specs use <non-terminal> = <actual-dfn> equations, but the parsing of that equation is not defined anywhere as far as we can tell. In practice, the <> are sometimes omitted on the left-side of the equation as in the inset() definition and content-list definition. In other cases, the = is not used at all as in the fade() definition. Some definitions also use a final semi-colon as in CSS Display, CSS Box Alignment and CSS Counter Styles.
Some specs extend the definition of a property with a "New value" field, which we understand must be combined with the actual definition with a | combinator. Unless we missed something, this is not described anywhere though.
The syntax talks about quotes, but does not explicitly define which quotes to use. Curly quotes get used in practice in most specs. We were rather reading "single quotes" as meaning the apostrophe ' character, still used in other specs (such as in CSS 2.2). Anything is fine, but it would be good to make that explicit in the Value Syntax Definition.
Some specs mix actual value definitions with prose. I reported the fill property in [fill-stroke] Missing quotes around property ref, and not a real "value" fxtf-drafts#300 for instance. Another example is the use of dagger characters to reference footnotes in the <an+b> definition. These values are not ambiguous for human beings, but makes automated parsing more challenging.
From time to time, some rules that could be defined with an = construct are actually defined in prose. For instance, <basic-shape> could perhaps be defined as <inset()> | <circle()> | <ellipse()> | <polygon()>, or <border-style> as none | hidden | dotted | dashed | solid | double | groove | ridge | inset | outset. The generic question is whether that is something that you'd like to encourage.
The syntax does not allow to define apparently "simple" things such as ranges or regular expressions. We noted the discussion in [css-values] Define value syntax that limits <integer>, <number>, <length>, etc. to ranges #355, so that's probably under way.
All in all, what we're wondering is whether it could be useful to end up with a CSS Value Definition Syntax that would allow the creation of a dump similar to the IDL index that appear at the end of API specs. For instance, for CSS Display Module Level 3, this dump could be:
display = [ <display-outside> || <display-inside> ] | <display-listitem> | <display-internal> | <display-box> | <display-legacy>
<display-outside> = block | inline | run-in
<display-inside> = flow | flow-root | table | flex | grid | ruby
<display-listitem> = <display-outside>? && [ flow | flow-root ]? && list-item
<display-internal> = table-row-group | table-header-group | table-footer-group | table-row | table-cell | table-column-group | table-column | table-caption | ruby-base | ruby-text | ruby-base-container | ruby-text-container
<display-box> = contents | none
<display-legacy> = inline-block | inline-table | inline-flex | inline-grid
CSS Flexbox would then complete the definition of display with:
display |= flex | inline-flex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3