Re: [css3-fonts] rethinking font load events

Thanks for the updated proposal, John. I'm coming from the perspective of what Typekit would need to replace our current implementation of font watching events in webfontloader with something backed by native browser functionality, while providing the same public-facing interface of font events to our end users. Our font events will need to continue to work in all browsers (including old ones that won't have this native functionality), but it'd be very nice to use this native stuff instead when it's available. It would be MUCH more reliable and efficient than our current method of creating spans on the page and monitoring their widths. I think your latest proposal has most of what we'd need.

One thing that I wanted to suggest is a per-font "loading started" event to pair with the onload and onerror events. Knowing when a particular font is detected as necessary for rendering on the page would help to provide more accurate loading events, and would also give the developer a precise idea of which onload/onerror events they were waiting for.

Tab Atkins Jr. wrote:
> Is that supposed to be the CSSFontFaceRule that actually kicked off
> the load?  Note that you can't expose that cross-origin.  This also
> means that to identify the font, you have to write
> "event.fontface.style.foo".  This is why I flattened the @font-face
> descriptors onto the event object - much shorter, and no cross-origin
> issues.

Cross-origin issues are also a big concern for Typekit. Our fonts get loaded on a bunch of different domains owned by our end users, but they're loaded from stylesheets that are served from Typekit domains. The JS running on their page still needs to be able to reliably detect these font loading events. Making one of the arguments an object from a CSSOM that the JS otherwise wouldn't have access to seems problematic. Instead, it seems like passing through a known (and possibly sanitized) set of strings as individual arguments might be a better approach to avoid those issues. If CSSFontFaceRule is later expanded, then you can separately decide whether those additions are also OK to include in the callback.

John Daggett wrote:
> In general, I'm still very skeptical that the per-font load events are
> needed at all.  I don't quite see what they give you unless there are
> other API's around that provide lower-level access to font matching
> and text shaping info.  I think it's a useful exercise to sketch out how
> per-font load events would work but by themselves I think it would be
> better to omit them from the first round version.  Web apps that want
> to do full-on text layout are going to need a much richer set of API's
> to do this sort of thing but I think the number of teams capable of
> doing this one can probably count on your hands (with maybe a toe or
> two).  Let's do the mainstream use case first and focus on the high-end
> use cases later.

Per-font load events are critical for Typekit to be able to adopt this as a replacement for font detection in new browsers. Typekit provides a set of per-font loading events to our end users, and we'll need to maintain that functionality going forward. It's also useful for our end users. Imagine a page where different modules each use a single font, and you want them each to display independently as soon as their respective fonts are ready. Or imagine a page like the Typekit browsing UI: each card uses a single font and renders as soon as we detect that the particular font is ready to render. This makes for a more responsive UI, with smaller fonts coming in sooner than more complex ones with a larger file size.

It's also critical to know exactly which fonts loaded and which had errors vs succeeded in rendering for our testing system that verifies that all of our fonts actually render in all of our target browsers. Not only should an error event fire for a particular font if none of the sources can be retrieved, but it should also fire if the font contains invalid data that prevents it from rendering.

- Sean

Received on Tuesday, 11 September 2012 11:55:38 UTC