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

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.

Right.

>> 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.

~TJ

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