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

On Sun, Apr 7, 2013 at 7:39 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.

Yes, that's the entire point of Futures.  All async programming is
just callbacks, and DOM Events (a particular idiom for callback use)
can be used to achieve the same thing as Futures (though every spec
that tries does it in a different way).  Futures is just a new
callback idiom for a particular common pattern.

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

Obviously, in a Worker the .fonts will hang off of the
WorkerGlobalScope rather than Document.  That's the only necessary
change.

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

That's literally just Hixie hacking around the lack of a concept for
"what fonts are currently available".  My FontList object provides the
same information in a non-abstract way.

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

Yes, I meant to copy over more of that, but didn't want to take up too
much space.  The intention is that resolution depends on the same
stuff that notifyWhenFontsReady() specifies.

>  This is irrelevant to worker threads which aren't accessing the DOM, I think they only need loadFont/checkFont.

Hm, interesting.  Why do they need checkFont()?

If workers don't need access to all the fonts, then it's simple for
FontList to just contain a list of CSSFontFaceRules instead of
specialized Font objects, and just add .ready() to CSSFontFaceRule.
That's a lot simpler.

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

Interesting!

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

Sure, I'll add these to the wiki.

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

Ugh, Font wasn't supposed to be an EventTarget.  No wonder Anne
thought something got fired on Fonts as well. :/  Fixed on the wiki.

If I could figure out some way to address use-case #3 without DOM
Events, I would, but I think that's actually the most natural fit.  I
think it's fine to mix callback idioms, as long as they're each doing
the right thing.

~TJ

Received on Monday, 8 April 2013 15:20:20 UTC