- From: Ryosuke Niwa via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2020 01:58:15 +0000
- To: public-css-archive@w3.org
> > 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`](https://drafts.csswg.org/css-font-loading/#font-face-set-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. -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1081#issuecomment-579557740 using your GitHub account
Received on Wednesday, 29 January 2020 01:58:17 UTC