Re: [css-font-load-events] Using Futures

Tab Atkins wrote:

> The Font Load Events spec is currently event-based, with a few
> ad-hoc callback-based APIs as well. It has an issue questioning
> whether it's worthwhile to switch to DOM Futures.  I believe it is,
> and have a suggested new API for doing so.

I can definitely see the advantage to Futures but frankly I think that the use of Futures seems more about cleaning up the API structure rather than serving as something that can't be achieved via callbacks or event handlers.  

A more important issue is the mechanism that worker threads use to load and use fonts.  Worker threads, defined in HTML5, don't have access to the DOM, so neither the FontLoader interface in the spec or your proposed FontList interface are available to them directly.  I think the intent is that somehow the font loading functionality will be avilable via what is labeled the "font style source object" in the HTML5 spec [1].

So before defining interfaces based on Futures, I think we need to have a clear idea of what worker threads need and don't need.  For example, if you look carefully at the definition of 'notifyWhenFontsReady', there's an interaction with not just font loading behavior but also with layout.  This is irrelevant to worker threads which aren't accessing the DOM, I think they only need loadFont/checkFont.

The other thing I think worker threads will need is a way to explicitly create and load new fonts.  It's not clear from your proposal whether the FontList is immutable or not but I'm guessing you were assuming it was a readonly, immutable collection of the @font-face rules defined in the union of all stylesheets for a given document.

However, I think the list of fonts needs to be mutable, even though that's significantly more difficult to spec.  The use case is for code like pdf.js which pulls in PDF data and generates image data on a canvas.  If that's in a worker thread it needs to be able to effectively create @font-face rules and load the related font data for those rules.  Without DOM access I think we'll need to come up with some way of doing this.

So I see two distinct but overlapping API's that need to be defined.  Once there's a clearer idea of the what and how of font loading needs of worker threads, I think we can address whether using Futures is the right approach or not.

One thing that would be helpful is if you could provide examples that demonstrate the use of the Futures-based API you're proposing, ones that match the examples in the spec for easy comparison.

Offhand, I think the mixture of EventTarget and Futures-based API's is a bit befuddling, especially each font being an EventTarget.  That seems somewhat cumbersome compared to the existing spec.  But like I say, I think we need to carefully lay out what worker threads need and don't need first, then work on the syntactic sugar.

Cheers,

John Daggett

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#text-styles

Received on Monday, 8 April 2013 02:40:28 UTC