Re: [css-fonts] grammar changes for @font-face and @font-feature-values rules

Le 28/04/2013 03:37, John Daggett a écrit :
> Based on recent syntax discussions, I've gone ahead and updated the
> CSS3 Fonts spec to define additional grammar productions for
> @font-face and @font-feature-values rules:
>
>    http://dev.w3.org/csswg/css-fonts-3/#font-face-rule
>    http://dev.w3.org/csswg/css-fonts-3/#font-feature-values

Hi John,

Yes this is much better, but I still have a few comments :)
Generally, I think that Media Queries and Conditional Rules are good 
models for this:

http://www.w3.org/TR/css3-mediaqueries/#syntax
http://dev.w3.org/csswg/css-conditional/#at-supports

The idea is to extend CSS 2.1 Appendix G, and make sure that everything 
is defined. To that end you can refer to §4.1.1 (the Core Grammar) or 
other specs.

In particular, I suggest adding:

> The following new definitions are introduced:
>
>     -    -|\\0{0,4}2d(\r\n|[ \t\r\n\f])?
>     F    f|\\0{0,4}(46|66)(\r\n|[ \t\r\n\f])?
>
> The following new tokens are introduced:
>
>     @{F}{O}{N}{T}{-}{F}{A}{C}{E} {return FONT_FACE_SYM;}

(You already have FONT_FEATURE_VALUES_SYM defined.)

I find this extension mechanism a bit silly, but that’s apparently 
that’s the way to do it until we switch everything over to Syntax 3. (At 
which point we will be able abstract away CSS escaping and say eg. "An 
at-keyword whose value is an ASCII-insensitive match for 'font-face'.")


AFAICT, the point of <descriptor_declaration> is to not have the <prio> 
production for !important. You could, like @supports, refer to 
<declaration> defined in the Core Grammar instead.


Whenever the grammar has S+, consider using S* instead. The difference 
is observable when using comment to separate tokens without whitespace:

     @font-feature-values Jupiter/**/Sans {}

We did require whitespace (ie. use S+) around operators in @supports and 
calc(), but I think this should be the exception rather than the rule. 
In this case, I think the most important is to be consistent with the 
'font-family' property. Quick testing shows that this is messy in 
implementations, I’ll start another thread …


No real issue with <feature_value_definition>, but you could also define 
it as a <declaration> and then describe the syntax of the values, as you 
do for @font-face descriptors.

-- 
Simon Sapin

Received on Sunday, 28 April 2013 08:56:17 UTC