- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 6 Sep 2012 09:01:25 -0700
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Sep 6, 2012 at 7:10 AM, John Daggett <jdaggett@mozilla.com> wrote: > Rethinking the font load event that Tab proposed, I think it would be > better to create a separate event target for font loads. Typical > patterns for load events in other Web API's rely on there being a > single target for one resource, typically an element. I'm fine with this. In particular, it prevents me from having to rename the events to something more unique, since it turns out that all the events that can hit a particular target must have unique names across all specs. (Btw, sorry for not posting up my feedback on my own proposal, like I said I would. ;_;) > partial interface Document { > readonly attribute FontLoader fontloader; > }; > > [Constructor] > interface FontLoader : EventTarget { > > // "idle" or "loading" > readonly attribute DOMString readyState; > > // event handler attributes > > // -- fires when readyState changes > [TreatNonCallableAsNull] attribute Function? onreadystatechange; I don't think this is necessary. There's only two states. Changing from "loading" to "idle" is handled by the below functions, and changing from "idle" to "loading" could probably use a better name. Note that we have a 'callback' type in WebIDL now, which all of these should use. That way you can define the arguments passed to the callback in IDL rather than prose. > // -- fires when all font loads have completed or failed > [TreatNonCallableAsNull] attribute Function? onallcomplete; In discussion, my coworkers and I thought the "all" name would be somewhat confusing. It's all the fonts *that the page has so far requested*, which means that the "allcomplete" event can fire multiple times in a page's lifecycle. I'm not sure what a better name is, though. How about just onidle? You can complement that with onloading for the opposite case. > // -- fires when a single font load completes > [TreatNonCallableAsNull] attribute Function? onload; > > // -- fires when a single font load fails > [TreatNonCallableAsNull] attribute Function? onerror; I don't think I like errors to trigger a separate event. I used a "usedSrc" attribute in the load event to indicate which source was chosen, which was nulled in case of error. > // async load > void loadFont(DOMString font, optional DOMString text); What do the arguments mean here? It looks like, from your example, the 'font' argument is meant to be a 'font' property declaration. I presume the 'text' argument, if supplied, specifies characters that must be covered by the loaded fonts (determined through unicode-range). > // notify completion, even if no fonts load > void notifyAfterCompletion(); I'm fine with things like this (simplifies interaction/API usually), but this is the reason promises are often better than events - you could just hinge some code on the allloaded promise and it'll either run immediately (well, in the next event loop cycle) or be held until the promise actually fulfills. I wish tc39 would hurry up and decide which flavor of promises they want to bless. :/ > The 'readyState' attribute switches between "idle" and "loading" > depending upon whether one or more fonts were loading at the time. When is readyState changed, relative to the other events? If you look at it in a load or allcomplete event, which state should it reflect? > The "load" and "error" events would fire the event below: > > [Constructor] > interface CSSFontFaceLoadEvent : EventTarget { > readonly attribute CSSFontFaceRule fontface; > readonly attribute DOMString error; > } > > Bubbles: only in my champagne darling > Cancelable: no Inheriting from Event, presumably. ^_^ 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. This also lacks the ability to tell which source was chosen in the load, which seemed useful in discussion with coworkers. My proposal had a 'usedSrc' attribute for that. ~TJ
Received on Thursday, 6 September 2012 16:02:23 UTC