- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Jan 2020 17:16:11 +0000
- To: public-css-archive@w3.org
> It says that the font should only be used if it "can be loaded 'immediately'". This needs to be clarified to allow for async loading from an on-disk cache, service worker, or other low-latency network source. I think it should be reworded to allow a "short" block period. The 100ms of bock periods elsewhere in the spec sounds fine to me. I'm not going to restore the exact language that I literally just removed due to complaints about it giving bad effects when read literally. ^_^ "Immediately" is scare-quoted and then immediately defined in terms of the necessary restriction it's imposing; as far as I can tell, that restriction (that the font be available in time for the first paint) allows all of the scenarios you mentioned? I very intentionally make no reference to the source of the font, precisely so that any of these can apply if the UA considers it reasonable. > It needs to say that the font blocks all rendering until it's known that the font won't come through in the block period, not just rendering of elements the font applies to. That's a knock-on effect of the next paragraph, dictating that loading an optional font *must not* cause layout to jump. (This allows subsequent elements to be rendered *if* the UA can determine they can't depend on the layout of the optional-font element, like if the optional-font is used in a layout-contained element or something.) > The font needs to always be loaded, regardless of whether it applies to any elements on the page. This is necessary to avoid extra, inefficient forced style or layouts, and allow the fetch (either from cache or network) to start as soon as the font element is parsed. This also is needed to mitigate the "blocks all rendering" behavior of item 2 above. I think this is an explicit anti-goal of this value; an "optional" font that is instead eagerly pre-loaded immediately on page load isn't very optional, I think. ^_^ Note the other functionality attached to the value, allowing the UA to abort the font load entirely if they know they're on a low-bandwidth connection, for example. An "optional" font is *explicitly intended* to be unreliable; the feature is aimed at being maximally friendly to users at the expense of authors' design preferences. An author can already preload fonts explicitly using the existing meta-preload functionality; combining that with `optional` to give you a better chance of hitting the "immediately available" window is a perfectly reasonable idea. ------ > This seems to suggest that subsequent elements may still render. See response to Chris's second point, above. > We need another thing that defines what browsers currently do when loading installed fonts. Is it a total render block? Eg will it block text selection throughout the page too? I'm assuming so. It is not, at least in Chrome. Loading an installed font from the disk cache can, today, result in a flash-of-unfonted-text for a frame or two if the call is slow. I think loading the generic fonts is blocking for rendering, tho. @xiaochengh has the details; I'm probably badly recounting what I remember them telling me. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4108#issuecomment-573124787 using your GitHub account
Received on Friday, 10 January 2020 17:16:13 UTC