[font-loading] "pending on the environment" not clear about what "document is still loading" means

[foolip]

https://drafts.csswg.org/css-font-loading/#fontfaceset-pending-on-the-environment

Given the other things on the list, this is probably supposed to match DOMContentLoaded timing or some document.readyState, but it doesn't link to anything that makes this unambiguous. Please link to something :)

@domenic @annevk @zcorpan

[foolip]

@Hexcles FYI (discussing what to do about https://crbug.com/507054)

[rniwa]

The order by which this flag is set is also important. It's unclear at which point relative to setting ready state, firing DOMContentLoaded or load event, this timing falls into etc...

There is an issue with the second bullet point as well. "The document has pending stylesheet requests" can occur multiple times even after the document had completely finished loading by inserting a new link or style element. Should we be going back & forth between not pending on the environment & pending on the environment?

Finally, the third bullet point has a reference to undefined the concept of pending layout operations. I don't even know what that means. Layout operations isn't a thing, is it? The third bullet point is even more problematic when we consider the prose which says "which might cause the user agent to request a font, or which depend on recently-loaded fonts". How does UA supposed to determine that? I don't think we can until we actually resolve all the computed styles. In fact, on web pages in which there is a never ending animation, UA can never determine that there is no pending task which can occur as a result of future layout changes caused by CSS / JS animations.

[tabatkins]

It's unclear at which point relative to setting ready state, firing DOMContentLoaded or load event, this timing falls into etc...

I think it's the "load" event - that waits until after stylesheets finish loading, right? Point of that condition is that you know all the styles that might cause a font to be requested.

Should we be going back & forth between not pending on the environment & pending on the environment?

Yes, you definitely go back and forth, and the spec has a note specifically calling out the fact that .ready() can return different promises across invocations due to this (if it went to "not pending" and resolved, and then more stuff happened which switched it back to "pending").

Finally, the third bullet point has a reference to undefined the concept of pending layout operations. I don't even know what that means.

Yup, style application and layout don't have good or precise terminology attached to them, unfortunately. I was forced to be handwavey here.

It's definitely later than when all computed styles are resolved, since it talks about layout; it thus can never happen before a layout finishes (to satisfy the guarantee talked about in the following note). The point is just that, if you wait for the ready promise to fulfill and then immediately go measure sizes/positions of things, you're not going to get burned by things resizing in the next frame or two due to fonts loading in.

Hm, I do suppose that an animation can change the 'font-family' being used. I'm happy to clarify that those shouldn't be considered, I guess.

[rniwa]

It's unclear at which point relative to setting ready state, firing DOMContentLoaded or load event, this timing falls into etc...

I think it's the "load" event - that waits until after stylesheets finish loading, right? Point of that condition is that you know all the styles that might cause a font to be requested.

But that would also wait for all subframes to be loaded. Is that what's intended here? FWIW, that's what I'm implementing in https://bugs.webkit.org/show_bug.cgi?id=205168.

Should we be going back & forth between not pending on the environment & pending on the environment?

Yes, you definitely go back and forth, and the spec has a note specifically calling out the fact that .ready() can return different promises across invocations due to this (if it went to "not pending" and resolved, and then more stuff happened which switched it back to "pending").

What's really bad is that ready is an attribute, which returns a different value each time. It's really bizarre.

+@bzbarsky on that point.

Finally, the third bullet point has a reference to undefined the concept of pending layout operations. I don't even know what that means.

Yup, style application and layout don't have good or precise terminology attached to them, unfortunately. I was forced to be handwavey here.

It's definitely later than when all computed styles are resolved, since it talks about layout; it thus can never happen before a layout finishes (to satisfy the guarantee talked about in the following note). The point is just that, if you wait for the ready promise to fulfill and then immediately go measure sizes/positions of things, you're not going to get burned by things resizing in the next frame or two due to fonts loading in.

But that could definitely happen because of DOM mutations, right? There is no guarantee that the DOM will stop changing at any given point.

As far as I tell, what you want is to wait for the load event to fire (or some other deterministic point is reached for document loading) then determine the set of fonts being loaded at that point (i.e. sync update the layout / style, which isn't really a concept so you don't even have to say it in normative text). As long as all those fonts are loaded, we should resolve the promise.

Otherwise, we'd never know when we're truly done loading fonts. Any script in the page can add a new style element or link element to load new fonts, and any DOM mutation like changing the attribute value can trigger new CSS selector to apply to that element and start loading new fonts since we can't predict the future with perfect precision.

[tabatkins]

But that would also wait for all subframes to be loaded. Is that what's intended here?

Probably not. Is there something I can hook which would say "all the DOM, scripts, and styles have loaded (but I don't care about subframes)"?

If not, "loaded" is still probably the best, just pessimistic. DOMContentLoaded fires before stylesheets finish loading, which is definitely too early.

What's really bad is that ready is an attribute, which returns a different value each time. It's really bizarre.

That is incorrect. The interface has an internal slot specifically for holding onto the promise that is given out by .ready; some of the spec algorithms replace that promise at certain times, but the following code should work:

let x = document.fonts.ready;
let y = document.fonts.ready;
console.log(x === y); // true per spec

But that could definitely happen because of DOM mutations, right? There is no guarantee that the DOM will stop changing at any given point.

Yup, which is why the third bullet refers to pending layout operations (not theoretical future ones) (aka styles that haven't been flushed yet, and the layout and potential font loads that would result from them), and the following note says "as long as nothing further changes the document".

[rniwa]

But that could definitely happen because of DOM mutations, right? There is no guarantee that the DOM will stop changing at any given point.

Yup, which is why the third bullet refers to pending layout operations (not theoretical future ones) (aka styles that haven't been flushed yet, and the layout and potential font loads that would result from them), and the following note says "as long as nothing further changes the document".

Given the concept of "pending layout operations" isn't defined, I don't think we can have a meaning conversation about how this interpretation is correct / incorrect but we need to re-define this *pending on the environment" concept without relying on such a fictional concept.

[tabatkins]

I mean, "pending" has a meaning: "about to happen; imminent". That precludes anything coming in from arbitrary future actions.

Regardless, tho, if you have any suggestions about how to talk about that more precisely, I'm all ears. The current state of the spec is the best I was able to come up with given the relative non-existence of precise timing/terminology around styling.

[rniwa]

Regardless, tho, if you have any suggestions about how to talk about that more precisely, I'm all ears. The current state of the spec is the best I was able to come up with given the relative non-existence of precise timing/terminology around styling.

Referring to my earlier comment, we should do this:

Wait for the load event to fire (or some other deterministic point is reached for document loading) then determine the set of fonts being loaded at that point (i.e. sync update the layout / style, which isn't really a concept so you don't even have to say it in normative text). As long as all those fonts are loaded, we should resolve the promise.

[bzbarsky]

+@bzbarsky on that point.

As @tabatkins said, its value does not change unless either the event loop has spun or an API call was made that changed its value, so it's no worse than innerHTML or readyState or a number of other attributes in that sense. So this part is fine. I haven't thought about the larger issue enough so far to comment intelligently yet; let me know if I should.