Re: [css3-fonts] new editor's draft

John Daggett <jdaggett@mozilla.com> wrote:
> Zack Weinberg <zweinberg@mozilla.com> wrote:
> 
> > * The phrase "Ranges that do not follow the syntax above" is
> >   confusing; suggest "Ranges that do not fit any of the above
> >   three forms".
> > 
> > * The term "ranges that have no meaning" is defined only by a
> >   nonexhaustive example -- if you mean "interval ranges where
> >   the second number is less than the first" please say so.
> > 
> > * You do not say what happens if some of the ranges in a list
> >   overlap each other.
> > 
> > * You do not say what happens if ranges specify code points greater
> >   than U+10FFFF.
> 
> Edits for these pushed.

Looks good, except:

# Although Unicode only defines character codes in the range U+0-10FFFF,
# values up to U+7FFFFFFF are allowed within unicode-range range lists. 

I'm all for allowing values that large, but the css2.1 core syntax for
UNICODE-RANGE tokens only permits six hex digits after the U+.  Up to
you if you want to ignore that.

> > This still does not give *syntax* for what goes inside the
> > parentheses, we need a specification in terms of CSS tokens.  I
> > suggest
> > 
> >   <font-face-name> : "local(" [ ID | STRING ] ")"
> 
> There are two issues here.  The first is whether or not to *require*
> quotes (since it's a string) and the second is the meaning of the
> value, what within font data it should match.
> 
> For the first issue related mainly to syntax, CSS has never enforced
> family names to be strict strings, quotes are not required.  So it
> seems natural to want to do the same with names within local().

That's fine (both here and for format()) -- I just want a nice clear
formal grammar for the unquoted case, preferably one that doesn't
require the implementation to concatenate tokens.  Hence the suggestion
of ID | STRING -- if the author's desired value happens to be a CSS
identifier, they can quote or not as they like, otherwise it must be
quoted.

> In your suggestion, what does 'ID' imply exactly, a CSS identifier?

Just so.

> As for the second issue, what the name within local() means, it will
> vary with format but I think we need to define this clearly for
> TrueType/OpenType fonts to assure cross-platform consistency.

I did not mean to express any opinion on the meaning of the name within
local().  I only brought up old-style X font names to illustrate that
not all plausible names are necessarily identifiers.

zw

Received on Wednesday, 21 January 2009 08:24:01 UTC