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

On Wed, Apr 8, 2015 at 10:16 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Tab Atkins Jr.:
>> 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.
>
> Yes, but we still have to follow the rules for the FontFace.load()
> method if a FontFace starts loading due to matching text in the
> document, so we still would have a place to explicitly invoke the
> “whenever … to having no pending font loads” algorithm, which is in the
> asynchronous part of the load() steps.
>
>> Are you suggesting this as *part* of the solution?  I think I'd also
>> have to hook the state-changing methods in FontFace, right?
>
> Yes I should have said that. :-)  All of the algorithms that mess with
> the status of a FontFace would need to explicitly invoke the algorithm.

Okay, I've switched all the "whenever" algorithms to instead
explicitly track the state of the FontFaceSet. I *think* I've done it
correctly, but I'd appreciate review.
<https://github.com/w3c/csswg-drafts/commit/b9923152182a54ccaf16330149049631af30912e>

I still had to have one "whenever" algorithm, to handle whenever the
"environment" isn't blocking a font load.  It invokes some things that
don't have hooks, so I'm not sure how else to write this.

> (By the way, according to current Web IDL, FontFaceSet must override
> add/delete/clear in the IDL because they have behaviour different from
> the default functions that get generated (which only do the argument
> type checking).  I really should add some terms to use from the add/
> delete/clear steps to manipulate the “set entries” so that it will
> forward those operations on to the backing Set.)

For now I'm writing it as directly manipulating the set entries. I'll
fix it up when you add better hooks to WebIDL.

~TJ

Received on Saturday, 11 April 2015 00:20:25 UTC