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

On Thu, May 28, 2015 at 12:49 AM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.

No, I'm taking the complete standard JS error-handling strategy of
"you're doing this wrong, here's an error".  As Florian says, HTML/XML
is irrelevant here; they're not parsed within a context that is
capable of catching or handling errors, so the most author-friendly
behavior is different there.  In JS, silently swallowing errors is
author-hostile.

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

Unfortunately, we can't tell the difference between a local font and a
downloadable font in a 'font' string.  Thus we can't distinguish
between a list that contains downloadable fonts (for which not finding
any of them is definitely an error) and a list that contains just
system fonts (for which not finding any of them *might* be an error
due to typos/etc, or just due to bad assumptions about system font
support).

I think the balance leans toward treating this as an error case,
particularly as this is the Font Loading API, and I suspect *not*
using downloadable fonts with it is probably a corner case.  It can be
avoided, in any case, by making your life easier and creating an alias
for that local font list with a @font-face containing only local()
sources; this makes it so you only have to type the list once, and
gives you error-checking against typos - win/win!

~TJ

Received on Thursday, 28 May 2015 23:30:25 UTC