Re: [css3-fonts] Comments on @font-face: local(...)

Erik Dahlstrom wrote:

> Yes I see from the definition of <family-name> that there are special
> rules for how to parse it when it's unquoted. I'm simply wondering if
> that has any nasty consequences, take for example a family-name like
> "}; * display: none;". That would be fine and wouldn't need either
> escaping nor quotemarks?
>
> Allowing the string to contain ")" can probably also be confusing. Let
> me rephrase my question: would allowing the unquoted and more-or-less
> unrestricted strings cause problems for user agents that don't support
> @font-face or would the error-handling rules of CSS take care of it?

I see your point, I think it makes sense to define the syntax of the
single name enclosed within local() to follow the rules for a single
name within a font-family list, since font-family has the same set of
problems with characters like }, ;, etc and since the whole reason for
allowing quotes to be omitted is to match the use of font family names. 
It makes sense to explicitly define characters that need to be quoted to
prevent problems on older platforms.

There's still one very tricky internationalization issue here, more
clearly defining non-English font name lookup, both for font family
names and for names used in local().  Support for localized family name
lookup across browsers is sketchy currently. With most Latin fonts this
isn't an issue since the font data doesn't contain localizations of
family names, Arial uses the same family name across locales.  But this
is an issue for CJK fonts, some platforms only match localized family
names when the OS and/or user locale is set to that locale, which leads
to inconsistency across browsers/platforms.

There's a similar issue with local() because style names are localized
in *lots* of languages and the set of localized names often changes with
font version (e.g. the font data for "Arial Bold" has localized
fullnames "Arial Negreta", "Arial Gras", etc. and set of names is
different on Win XP, Vista, Win7).  I think it makes sense to simply use
the English name as the "canonical name" for local() lookup, since
Microsoft suggests that OpenType fonts always contain this and allows
English name lookup under all localized versions of Windows. This was
discussed briefly at the CSS March F2F but I still haven't put clear
wording into the spec.  Not the ideal from an internalization standpoint
and it would be somewhat inconsistent with localized font family name
usage but it would assure fewer hiccups across implementations/platforms.

> Minor nit: I'd like it very much if all the definitions had id's and
> were linked to from where they were used in the spec, one example is
> the <family-name> production which is used from a bunch of different
> places.

Makes sense, I've been meaning to clean up internal links in the spec.

> What about a case like this:
>    @font-face { src: local(foo) }
> 
> Does the spec forbid conforming UA:s from using that font since it
> doesn't have a defined family-name in the @font-face rule? I couldn't
> find such wording, though it is implied that that's the desired
> behavior.

Right, both font-family and src descriptors are required in @font-face
rules; without properly formed font-family and src descriptors an
@font-face rule is omitted completely.  The spec should state that more
clearly.

One ever so subtle ripple here is that even if the loading of all fonts
listed in the src list fails, the font matching behavior does *not* match
a situation where the @font-face rule is omitted.

  @font-face {
    font-family: BodyTextFont;
    src: local(RegularFont), url(fonts/RegularFont.ttf);
  }
  
  body { font-family: BodyTextFont, Times, Georgia, serif; }
  
If a given user happens to have a font with a family name "BodyTextFont"
on their system it should *never* be used in the example above; either a
locally available RegularFont or a downloaded version of Regular font
will be used.  If both of these are available or fail to load, fallback
to "Times, Georgia, serif" should occur.  The locally available version
of BodyTextFont should *not* be used unless it is defined as the local
version of serif or as a general default font.  Conversely, the use of
BodyTextFont should not affect default font display except in cases
where a user agent explicitly allows definition of serif and sans-serif
via @font-face rules.

Testcases for this:
http://people.mozilla.org/~jdaggett/font-face/name-collision.html
http://people.mozilla.org/~jdaggett/font-face/name-collision-bad-url.html

No user agent currently does this correctly. :(  And the spec should
probably have better wording and an example to illustrate this.

>> Whether a local face or a downloaded face is used, this is a family
>> with a single face, the style matching is the same in either case.
>
> That sounds good. Are you saying that it's fully defined by the font
> matching algorithm in section 5? IMHO the wording is quite loose for
> step 3, nothing there says how a font is "labeled" with particular
> properties, would be nice if that could be made more explicit.

Agreed, the font matching algorithm wording is definitely too loose
currently and should explicitly note how synthetic rendering affects
matching behavior.

>> Fake slanting, double striking, these are all hacks. Synthetic faces
>> suck, I take that as a given.  This is not confined to @font-face
>> fonts, either local or downloaded, it's the same for normal platform
>> fonts; they don't render the same across browsers.  Saying it's "not
>> always possible" is wrong, it's just not always easy to coax API's to
>> do what you want (oh I do so love Windows GDI). But I think
>> differences in synthetic rendering of @font-face defined faces is
>> completely under author control; define four faces for a given family
>> and you'll never see synthetic rendering!!
> 
> That's acceptable, how about adding an (informative) authoring note to
> that effect in the spec?

That sounds like a great idea.

John Daggett
Mozilla Japan

Received on Friday, 21 August 2009 02:15:00 UTC