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

Re: [css-font-loading] load, check and testing for character coverage

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 28 May 2015 16:49:47 +0900
Message-ID: <CALYZoVN1Osr=X4351ZX-DfTeDv+0kwoSQM0=CAYJ5c8WwPSFXQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Tab Atkins wrote:

> This is a reasonable argument.  So we have two cases:
>
> : "find the matching font faces" algo can't find *any* of your font faces
> :: This is an error case. Either the author typo'd a font name, or
> they changed their font names and didn't update all the old usage
> sites. No possible legitimate usage.
>
> : "find the matching font faces" algo finds fonts, but filters them
> all out for not being able to render the "sample text"
> :: This is acceptable, it just means that the text will get rendered
> with an (unspecified) fallback font. No load is required.
>
> I'm fine with making the algo a little smarter, and treating these two
> cases differently.  This'll capture the desired error behavior (by
> throwing) and your desired example behavior (by returning true).  I
> just committed a change to handle this.  Please review and let me know
> what you think. ^_^

I feel like we're playing a rerun of XML vs. HTML error handling. Your
view is the XML view, "this is not right, bad you", errors should be
returned. What I'm saying is the HTML view, "this is not right but we'll
deal with it", no errors other than maybe a warning in the dev console
if that's appropriate.

Fontlists used with the check() method may or may not include
downloadable fonts. Platform fontlists *never* cover all possible
platforms and authors are often only vaguely aware of their platform
coverage. If a given fontlist only uses platform fonts and you happen to
be on a platform that doesn't support those fonts, this method will throw
for no really good reason.

Example:

  A site uses a downloadable font for Latin text but not for other
  scripts. They use different fontlists for different locales. Some use
  downloadable fonts, others do not.

    // uses downloadable font, so doesn't throw
    check("16px MyDownloadableFont, Helvetica, Lucida Grande", "Edit");

    // no downloadable font, throws on Windows XP, Android, Linux
    check("16px Meiryo, Hiragino Kaku Gothic Pro", "編集");

The 'check()' method shouldn't be transformed into some sort of fontlist
validation method. It shouldn't throw or return an error when no fonts
can be found because the combination of possible text contents and fonts
is not something authors generally "validate" in this sense, just as
they don't validate the usage of font shorthands in other API's (e.g.
Canvas context, element.style).

Regards,

John Daggett

​
Received on Thursday, 28 May 2015 07:50:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC