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

Le 28/04/2013 10:55, Simon Sapin a écrit :
> 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 …

It appears that this is not worth an entire new thread: I think that the 
spec already says what it should here:

> If a sequence of identifiers is given as a font family name, the
> computed value is the name converted to a string by joining all the
> identifiers in the sequence by single spaces.

Test case:

     data:text/html,Test<style>body{font-family:Fontin/**/Sans

Change the font family to one installed on your machine, that you can 
tell apart from the default font, and whose name contains a space. 
Replace the space by a comment, as above. The test passes if the font is 
still applied.

Passes in Chrome, fails in Firefox. (I don’t have IE to test, and didn’t 
manage at all to use a font with a space in the name in Opera Linux.)

I think the spec is already clear enough, and this is a Firefox bug 
(that I’ll report.)

-- 
Simon Sapin

Received on Sunday, 28 April 2013 09:56:12 UTC