W3C home > Mailing lists > Public > www-style@w3.org > April 2013

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Sun, 28 Apr 2013 11:55:49 +0200
Message-ID: <517CF225.1080308@exyr.org>
To: John Daggett <jdaggett@mozilla.com>
CC: www-style list <www-style@w3.org>
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:


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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC