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

On 30/05/2012 19:45, Bert Bos wrote:
> On Monday 28 May 2012 10:05:32 Anton Prowse wrote:
>> On 28/05/2012 04:57, John Daggett wrote:
>>> Anton Prowse wrote:
>>>>> Proposed:
>>>>>      Unquoted font family names that happen to be the same as the
>>>>>      keyword values 'inherit', 'default' and 'initial' or the
>>>>>      generic font keywords ('serif', 'sans-serif', 'monospace',
>>>>>      'fantasy', and 'cursive') do not match the '<family-name>'
>>>>>      type. These names must be quoted to prevent confusion with
>>>>>      the keywords with the same names. Note that 'font-family:
>>>>>      Times, inherit' is therefore an invalid declaration, because
>>>>>      'inherit' in that position can neither be a valid keyword
>>>>>      nor a valid font family name.
>>>>
>>>> I like the normative first sentence, but I think the second
>>>> sentence should be bundled up with the non-normative note.  This
>>>> would alleviate my concern that it's not clear from the tone
>>>> whether 'must' is an authoring recommendation or a conformance
>>>> requirement; does not quoting result in an invalid value or
>>>> merely "confusion"? (In reality, whether or not it's invalid
>>>> depends entirely on the value definition and the global
>>>> grammar/syntax etc, which is captured succinctly by the normative
>>>> first sentence.)
>
> I agree that the second sentence is redundant. But I prefer leaving it
> as is, because it nicely explains both the reason for and the
> implication of that rather dense first sentence.
>
>>>>
>>>> I also think the last sentence (the example) doesn't tie in
>>>> correctly with the the first sentence, since it's not the
>>>> /position/ of 'inherit' that causes it not the be a valid font
>>>> family name; rather, it's the fact that it isn't quoted.
>
> The example isn't about whether "inherit" is a family name or not, but
> about whether the example is valid syntax. A very similar example such
> as 'font-family: inherit' isn't quoted either and is valid nevertheless.

OK, but then what does the "therefore" refer back to in the third 
sentence?  I feel that the third sentence doesn't capture what you're 
describing, because it seems to refer back to the second which doesn't 
touch on the point you just made in any obvious way.

> The grammar on its own says "inherit" in this position can only be a
> <family-name>, but the English text says it isn't. So all we know is
> that the example cannot be parsed. "Inherit" here is neither a family
> name nor a keyword, just a syntax error.

Hmm, thanks for pointing this out.  I missed the subtlety that when 
'inherit' is rejected for not matching <family-name>, it's not then 
reinterpreted as a keyword; the whole value is merely rejected as invalid.

>>> I don't really agree with you here, I think both the context of the
>>> 'must' is fine and I think the example in the third sentence is
>>> simply saying that 'inherit' is valid but 'foo, inherit' is not.
>>> Before 'foo, inherit' could have been interpreted as
>>> matching<family-name>, which was part of the ambiguity.
>>>
>>>> I suggest:
>>>>      | Unquoted font family names that happen to be the same as the
>>>>      | keyword values 'inherit', 'default' and 'initial' or the
>>>>      | generic font keywords ('serif', 'sans-serif', 'monospace',
>>>>      | 'fantasy', and 'cursive') do not match the '<family-name>'
>>>>      | type.
>>>>      |
>>>>      | Note: These names must be quoted to distinguish them from
>>>>      | the keywords with the same names.  For example, the
>>>>      | declaration 'font-family: Times, inherit' is invalid
>>>>      | because 'inherit' is interpreted as the keyword, resulting
>>>>      | in an invalid value.
>
> John's last sentence is better. The word "inherit" isn't interpreted as
> a keyword, it isn't interpreted at all.

I agree that my third sentence isn't good enough, in the light of my 
comment above.

>>> However, if you think splitting the proposed text into two
>>> paragraphs to distinguish the normative requirement from the
>>> authoring note, I'm fine with your tweak of this.
>>
>> Whilst I quite strongly prefer my use of "distinguish" to the current
>> use of "confusion", I'm happy to leave it to you to choose between
>> the two proposals.
>
> I prefer "confusion." The quotes do indeed distinguish two cases, but
> the cases aren't always names and keywords. Sometimes the cases are
> valid and invalid (e.g., '"initial"' vs 'initial').

Right.

>> In your proposal, I don't think it's necessary to split the note off
>> into a separate paragraph. ("Inline" notes are fine when they're only
>> one sentence long, I feel.)
>
> In summary, I prefer John's text, but some mix of John's and Anton's
> would be fine, too.

So, I retract my proposed second and third sentences, as they don't 
successfully capture the issue.

My qualms with John's proposed sentences still stand though, for the 
reasons I described earlier (which are quoted in this post).

Would the following satisfy all of us?

   | Unquoted font family names that happen to be the same as the
   | keyword values 'inherit', 'default' and 'initial' or the
   | generic font keywords ('serif', 'sans-serif', 'monospace',
   | 'fantasy', and 'cursive') do not match the '<family-name>'
   | type.  In order for them to be interpreted as font family names,
   | these names need to be quoted. Note: for example,
   | 'font-family: Times, inherit' is an invalid declaration, because
   | inherit' in that position can neither be a valid keyword
   | nor a valid font family name.

My changes swap out the "must", remove the "confusion" because I don't 
think the original sentence clearly indicated the ways in which 
confusion could arise, and remove the "therefore" because I don't find 
it clear which part(s) of the preceding prose it refers back to.

Again, I'm happy to leave it to others to choose.  I don't seek further 
analysis of my above proposal or justification for that choice, if it 
now simply boils down to editorial preference.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 31 May 2012 07:43:27 UTC