Re: [css3-fonts] rethinking font load events

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