W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[css2.1][css3-fonts] keywords in unquoted font family names

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 17 May 2012 23:34:25 -0700 (PDT)
To: www-style list <www-style@w3.org>
Message-ID: <1803357781.16019199.1337322865813.JavaMail.root@mozilla.com>

I wanted to follow up on some of Bert's comments regarding reserved
keywords and the syntax of font family names at the F2F and try again
to propose more precise wording that will allow proper testing of this
issue.

On the telcon a few weeks ago there was a discussion about situations
like these:

  font-family: foo, inherit;

I don't actually see how the present wording explictly makes 'inherit, foo' 
invalid but not 'foo, inherit'.  Specifically, I'm not sure I see an implicit
priority in the grammar productions that distinguish 'foo, inherit' from
'inherit, foo'.

Both Tab and Elika feel that any unquoted name that includes
keywords like 'inherit' should be invalid, so declarations like
the ones below would be invalid:

  font-family: foo inherit;
  font-family: inherit foo;

I put together some tests for this (Javascript required):

  http://people.mozilla.org/~jdaggett/tests/font-family-parsing.html

As you can see, the results vary widely.  Webkit treats as invalid any
declaration that includes a font name with 'inherit' or 'initial'. 
Firefox only throws out declarations that begin with 'inherit' and not
much else.  IE9 is simply bizarre, it almost never invalidates
'font-family' declarations but does invalidate, sometimes, within
'font' declarations.

I think the real problem is the wording below in CSS 2.1 (and in CSS3
Fonts):

  Font family names that happen to be the same as a keyword value
  ('inherit', 'serif', 'sans-serif', 'monospace', 'fantasy', and
  'cursive') must be quoted to prevent confusion with the
  keywords with the same names. The keywords 'initial' and
  'default' are reserved for future use and must also be quoted
  when used as font names. UAs must not consider these keywords
  as matching the '<family-name>' type. 

This is written from the point of view of the author, it doesn't
completely define which situations produce valid declarations and
which ones don't.  The term "these keywords" in the last sentence
needs to apply to 'inherit', 'default' and 'initial'.

I think the answer here is to come up with wording that explicitly
defines as valid/invalid the rules below:

  /* valid */
  font-family: inherit foo;
  font-family: foo inherit;
  font-family: initial foo;
  font-family: foo initial;
  font-family: default foo;
  font-family: foo default;

  /* invalid */
  font-family: inherit, foo;
  font-family: foo, inherit;
  font-family: initial, foo;
  font-family: foo, initial;
  font-family: default, foo;
  font-family: foo, default;

In terms of CSS 2.1 errata, I would propose two changes:

1. Correct the syntax to fix the placement of the comma:

Existing:
   font-family: [[<family-name> | <generic-family>] [, <family-name>| <generic-family>]* ] | inherit

Proposed:
   font-family: [[<family-name> | <generic-family>] [, [<family-name>| <generic-family>]]* ] | inherit

2. Make the wording less ambiguous:

Existing:
  Font family names that happen to be the same as a keyword value
  ('inherit', 'serif', 'sans-serif', 'monospace', 'fantasy', and
  'cursive') must be quoted to prevent confusion with the
  keywords with the same names. The keywords 'initial' and
  'default' are reserved for future use and must also be quoted
  when used as font names. UAs must not consider these keywords
  as matching the '<family-name>' type. 

Proposed:
  Font family names that happen to be the same as the keyword values
  'inherit', 'default' and 'initial' are not allowed to match the
  '<family-name>' type. These names or those that match generic font
  keywords ('serif', 'sans-serif', 'monospace', 'fantasy', and
  'cursive') must be quoted to prevent confusion with the keywords
  with the same names.

If this makes sense, I can align the wording in CSS3 Fonts to match
this and provide more explanation and examples of valid/invalid usage.

Regards,

John Daggett
Received on Friday, 18 May 2012 06:34:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT