W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 10 Apr 2015 17:19:37 -0700
Message-ID: <CAAWBYDCGWnbCbBjXqQLoXBRpN=Jx8VQaus_txQKgCwnxVo+giw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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.

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:53 UTC