W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Myles C. Maxfield <mmaxfield@apple.com>
Date: Thu, 31 Mar 2016 19:49:46 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-id: <2A20DA27-5F2E-4149-8920-0D424DE4632D@apple.com>
To: John Daggett <jdaggett@mozilla.com>

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

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.


> > 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
> ​
Received on Friday, 1 April 2016 02:50:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC