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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 18 May 2012 09:20:09 -0700
Message-ID: <CAAWBYDBrA35tEE+7nugBkhbA22cfYQEykp9qr3yUo-mrvyP7CA@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: www-style list <www-style@w3.org>
On Fri, May 18, 2012 at 12:53 AM, John Daggett <jdaggett@mozilla.com> wrote:
> Tab Atkins Jr. wrote:
>> >  /* 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;
>> I still support my and fantasai's assertion that any use of the
>> reserved keywords are invalid; in other words, the <user-ident> type
>> simply does not include those keywords.
> I think unquoted font family names are special unique beasts, they are
> essentially a unique type equivalent to ident+.  The more I think
> about it I don't think they can be defined based on the CSS3 Values
> definition of identifiers.
> Look at the definition of <user-ident> in CSS3 Values (called
> <identifier> in the current draft) [1], it's meaning varies depending
> upon the context in which it's used:
>  Some properties accept arbitrary user-defined identifiers as a
>  component value. This generic data type is denoted by <identifier>,
>  and represents any valid CSS identifier that does not otherwise
>  appear as a pre-defined keyword in that property's value definition.
> In the context of the definition of font-family, that would imply that
> the generic font family names were *not* matched by <user-ident>+ so
> both declarations below would be invalid using this definition:
>  font-family: inherit foo;
>  font-family: sans-serif foo;
> From an implementation point of view it's weird to be checking *both*
> individual ident tokens to see if they are keywords (e.g. inherit,
> initial) and a sequence of ident tokens to see whether they match a
> generic name (e.g. sans-serif).

Hm, that's valid.

> Another weird edge-case example exists in the way 'font' shorthand values
> are parsed:
>  font: caption;        /* use the system font settings for captions */
>  font: medium caption; /* use a font named "caption" */
> The definition of <user-ident> would imply that the second declaration
> was invalid, since <user-ident> could only match values that were not
> otherwise keywords.


>> Browsers are inconsistent, but I highly doubt there's any compat risk
>> whatsoever.  We should be able to make this sane without any problem.
> Agreed, this isn't a question of compat risk.  But I disagree that
> defining the syntax of unquoted font family names in terms of
> user-defined identifiers qualifies as sane.  I think the "sane"
> change you're proposing has lots of ugly nuances that are bad for
> implementations without changing much for authors (since they won't
> be using fonts named "foo inherit" anytime soon).

Okay, granted.

In that case, define your idents in terms of the IDENT production in
the grammar.

Received on Friday, 18 May 2012 16:21:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:59 UTC