Re: [css-font-loading] “whenever” algorithms

On Wed, Mar 18, 2015 at 12:00 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> One additional reason for moving away from “whenever” algorithms is that
> it is possible for two different “whenever” algorithms to be triggered
> at the same time, and it is not defined which order their steps are run.
>
> For example, consider:
>
>   assert(document.fonts.status == "unloaded");
>   document.fonts.add(new FontFace("test", "url(some-font)");
>
> When the font finishes downloading, we are in step 5 of
> http://dev.w3.org/csswg/css-font-loading/#font-face-load.  Step 5.2
> updates the FontFace’s status attribute to “loaded”.  At that moment,
> both the
>
>   Whenever one or more available font faces for a given FontFaceSet
>   change their status attribute to “loaded” or “error”, …
>
> and
>
>   Whenever a FontFaceSet goes from having possibly pending font loads to
>   having no pending font loads, …
>
> conditions are triggered.  Clearly, to get the expected behaviour of the
> FontFace being exposed on the loadingdone event, you need to run the
> former algorithm’s steps before the latter’s.  But it’s not well
> defined.

Good catches, and I agree that this needs to be nailed down more
precisely.  Ordering bugs are terrible. :/

However, I'm not sure how your suggestion (in the parent email) to
handle this by hooking the FontFaceSet add/delete/clear() methods
would work.  For example, "Whenever a FontFaceSet goes from having
possibly pending font loads to having no pending font loads" triggers
when fonts just finish loading, even if they've just been sitting in
the set unmolested this whole time.

Are you suggesting this as *part* of the solution?  I think I'd also
have to hook the state-changing methods in FontFace, right?

~TJ

Received on Wednesday, 18 March 2015 23:40:02 UTC