The CSS3 Fonts spec defines the interface for a FontLoader object that implements support for font load events and methods dealing with font loading. This is still under discussion but I thought I'd log this to put it on the radar of folks for possible implementation.

The difference between checkFont and isFontAvailable is very unclear. At least it would be good to document the difference explicitly. Clarifying the difference using more descriptive names might also be appropriate.

(In reply to Jonas Sicking (:sicking) from comment #1) > The difference between checkFont and isFontAvailable is very unclear. At > least it would be good to document the difference explicitly. Clarifying the > difference using more descriptive names might also be appropriate. Poor editing on my part, checkFont was intended to replace isFontAvailable. Update pushed.

Spec has been pushed out into a separate spec: http://dev.w3.org/csswg/css-font-load-events-3/

Needed for important content use cases like pdf.js and other canvas clients.

Needed for Firefox DevTools (font inspector).

This is also needed for Firebug[1]. Further note that the CSS Working Group decided to use Promises for the font loading API[2]. Sebastian [1] http://code.google.com/p/fbug/issues/detail?id=6579 [2] http://lists.w3.org/Archives/Public/www-style/2013Jul/0080.html

Just checking the room temperature (I hope this is the appropriate place): I'm taking care of Chromium's implementation of said API (crbug.com/53213 in progress and available behind our experimental flag). I see that various folks have chimed in with use cases and from what I heard at the AtypI conference last week, I can confirm that a lot of folks were eager to see this API. John, any rough idea of a timeline for Firefox? Any concerns that needs to be worked out beforehand? Thanks!

The spec needs more work but I'm hoping that work can wrap up in a couple months. Then it's just a matter of getting someone to work on the implementation end of it.

Specification has changed to using Promises in addition to event handlers: http://dev.w3.org/csswg/css-font-loading/ Each @font-face rule and dynamically loaded font is represented by a FontFace object: FontFace object readonly attribute FontFaceLoadStatus status; Promise load(); attribute Promise loaded; The set of all @font-face and dynamically loaded fonts are included in a FontFaceSet object: FontFaceSet object attribute EventHandler onloading; attribute EventHandler onloadingdone; attribute EventHandler onloadingerror; // check and start loads if appropriate // and fulfill promise when all loads complete Promise load(DOMString font, optional DOMString text = " "); // return whether all fonts in the fontlist are loaded // (does not initiate load if not available) boolean check(DOMString font, optional DOMString text = " "); // async notification that font loading and layout operations are done Promise ready(); // loading state, "loading" while one or more fonts loading, "loaded" otherwise readonly attribute FontFaceLoadStatus status; For normal, main-thread situtations, script can access fonts via the document.fonts object which is a FontFaceSet. The FontFaceSet object does *not* include platform fonts, only @font-face and dynamically loaded fonts. The FontFaceSet exists independent of CSS OM objects for @font-face rules. At this point I think we're down to refining details of the spec and it will move to LC/CR soon. Tab is currently the editor.

Note: we may need to break out a separate bug for backend work in the userfont set but at this point that seems fairly minimal in terms of the effort required. Also, an implementation for this has landed in the Blink tree and there are plans to enable this by default in Chrome soon.

It's still unclear to me what the purpose of having FontFaceSet be a SetClass is. The only part of SetClass that seems useful is the .add(FontFace). But the .clear(), .has(), .keys() and .values() functions seems less clear to me that they are useful. I guess .delete() is useful since it's the only way to unload a font? In other words, what is the purpose of making FontFaceSet be a map key'ed on FontFace instances? An Array of FontFace isntances seems more close to what is needed here. I'm also not sure if the "Modifications of normal Set methods" section [1] is actually implementable. What happens if a page calls Set.prototype.delete.call(fontFaceSet, someFontFaceInstance)? Will that also throw as defined by that that section? Likewise, will calling Set.prototype.add.call(fontFaceSet, new FontFace(...)) cause the font-face to be added to the page? If so, how will that be implemented? [1] http://dev.w3.org/csswg/css-font-loading/#set-modifications

I agree, as SetClass is currently defined. I've mailed Tab (just earlier today) to hash out something more sensible.

One suggestion I had was just to remove the [SetClass], put add etc. functions on the interface as well as an iterator. That would let you do |new Set(document.fonts)| so you could call the other Set methods on it. Still, things like forEach and values would work just as well on an array that you could get by doing |Array.from(document.fonts)|.

I ended up forgetting about this open bug and did the work in bug 1028497. Duping to that one.