Re: [css-counter-styles][css-fonts] Editorial: syntax of declarations

Simon Sapin wrote:

>>> We all know what that means, but the specs should still have a
>>> normative definition of the syntax that encodes all the corner
>>> cases. The trends seems to be a formal grammar that extends CSS
>>> 2.1 ยง4.1, but "like declarations in style rules" with a normative
>>> reference to CSS 2.1 would work for me too.
>>>
>>> Alternatively, refer to "parse a list of declarations" in Syntax
>>> 3, but see
>>> http://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html
>>>
>>> (Based on http://wiki.csswg.org/spec/cssom-constants , this should
>>> be everything that uses the declaration syntax. Not counting @page
>>> which allows mixed declarations and at-rules. Did I miss anything?)
>>
>> We shouldn't be writing explicit grammars for simple cases like
>> this. It's long been my intention to write up several helper
>> constructions in Syntax, to make grammars more like what Fonts and
>> Counter Styles do both easy and precise.
>>
>> I haven't been working on Syntax lately, but I'll pick it up again
>> soonish.
> 
> Agreed. This is what I mean by "like style rules" and refer to 2.1,
> or refer to Syntax 3.

Thanks for starting this thread Simon, I actually was thinking about this last week while fiddling with the implementation of @font-feature-values.  

While something that Tab puts together in the future may solve all of our problems for all time, I think it makes since to add grammar for the @-rules defined in the Fonts spec just as CSS Animations and CSS Conditional do.  I think we can get away with reusing the "like style rules" fudge, but we should explicitly state that the 'prio' term is always omitted for descriptors.

This might be unrelated, but I noticed that there's an interesting pattern involving the handling of the semi-colon *between* @-rules in most CSS parsers:

  @bongo  /* no {} block */

  @font-face {
    font-family: test1;
    src: url(...);
  }

  @bongo ; /* no {} block but semi-colon */

  @font-face {
    font-family: test2;
    src: url(...);
  }

For the two cases above, all browsers that I tested didn't parse the test1 font rule but *did* parse the test2 rule.  This behavior is consistent but I don't see how this follows from the 2.1 grammar definition.

Because of the recent syntax change to the @font-feature-values rule, this behavior also affects cases like the one below:

  @font-feature-values fantastic font, crappy font {
    @bongo
    @styleset { crossed-w: 3; }
  }

Does the syntax error in the line containing '@bongo' cause the definition of 'crossed-w' to get eaten as part of the error handling?  Would that change if the first line was '@bongo ;' instead?

Cheers,

John

Received on Monday, 22 April 2013 05:07:41 UTC