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

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.

> 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!

I don't think viewing this as a "corner case" is correct. Complex sites
use different fontlists in different situations, as I've already shown
in examples. They may include downloadable fonts for some locales but
not for others. They may include them for a desktop version of the site
but not for the mobile version. If fontlists can generate exceptions via
the check() method in some situations but not others you're going to
cause some very hard to find site bugs with this method, bugs that are
not due to any real error but simply reflect that system fallback fonts
were used instead of fontlist fonts in some situations.

I think you're viewing this validation feature of the check() method as
a handy addition to its core function of checking the load state of
downloadable fonts in the list, independent of other fontlist usage on
the web platform. I think it's important to be consistent with other
fontlist usage. Making *just* this method act as a validation method is
inconsistent with the use of fontlists in other situations where no such
validation occurs.

Assuming "Bongo" is a non-existent font on a given platform, other
situations where the font shorthand is used neither throw or otherwise
return any form of error (nor should they!):

  element.style.font = "16px Bongo";
  ctx.font = "16px Bongo"; // canvas use

I don't think the check() method should throw or report errors for this
case either.

The check() method is only marginally useful since authors can simply
always structure their code to use load() and avoid the extra step of
calling check() first. So I think if we can't agree to omit the extra
validation error/throwing behavior of check() we should simply drop the
method altogether.

Regards,

John

​