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

On Thu, Mar 31, 2016 at 7:49 PM, Myles C. Maxfield <mmaxfield@apple.com> wrote:
> On May 28, 2015, at 5:51 PM, John Daggett <jdaggett@mozilla.com> wrote:
>> Tab Atkins wrote:
>>>> 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.
>>
>> There may be cases where fontlists that include only fonts that don't
>> exist on a given platform are actually an authoring error (e.g. a
>> misspelling) but there are other cases that I've already included where
>> they are *not* errors, they simply reflect the natural way authors
>> always use fontlists. Throwing exceptions here is author-hostile behavior.
>
> Sorry for resurrecting an old thread, but now that I’ve been working on implementing this API in WebKit, I would like to chime in. I definitely agree with John about it being hostile for check() to throw an exception. The whole point of this function is for an author to find some information without side-effects. John’s previous argument about empty match lists being expected is definitely true. Websites are created for many different configurations, for many different platforms, devices, locales, bandwidth speeds available, etc. This is definitely not an "error condition."

I did not add the error-throwing step for no reason.  We had author
reports *on this very list* from people using early Chrome
implementations that they'd removed a font from the page, but were
still accidentally checking for it with .check() and got "true", and
found that very confusing.

I have not so far heard *any* justification for why calling .check()
with a font that *does not exist* is something that an author would
want to do on purpose, or would run into accidentally in the course of
normal programming.  The only situations where this seems to occur are
(a) the author typo'd a font, or (b) the author changed the name of a
font or removed it, and forgot to update the .check().  Both of these
are clear authoring errors and the author is *helped* by having it
break in an obvious way.

I'm not going to entertain any arguments comparing JS error-handling
vs CSS or HTML error-handling, as the two groups of languages have
very different philosophies on whether errors are *ever* indicated to
the author, and so comparing them is pretty worthless.

> Instead of throwing, the best option is to return true. Because it does not perform the additional ‘cmap’ verification, the check() function cannot be used to know if a string can be successfully rendered with a font. Instead, it must only be used to check if additional loads are required. No matching fonts means no additional loads are required.
>
> Put another way: A return of “true” is more or less meaningless (more loads might be necessary, but they might not). A return of “false” means “more loads are definitely necessary.” An empty match list fits into the first category, and does not fit into the second.

If we ignored the possibility of throwing an error, I agree, returning
true is the correct answer.  But we throw for a reason.

~TJ

Received on Friday, 1 April 2016 16:01:58 UTC