- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 16:29:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts] Add a font-display keyword to eliminate @font-face FOIT & layout shifts`. <details><summary>The full IRC log of that discussion</summary> <dbaron> Topic: [css-fonts] Add a font-display keyword to eliminate @font-face FOIT & layout shifts<br> <Rossen_> s/Resolution:/RESOLVED:/<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/7271<br> <dbaron> xiaochengh: I propose adding a new keyword to font-display descriptior so it's critical and blocks load event of stylesheet.<br> <dbaron> xiaochengh: The purpose is to eliminate flash of invisible/unstyled text or layout shift caused by web fonts.<br> <dbaron> xiaochengh: There are many ways to mitigate flash or layout shift, but either complicated to use or have other issues.<br> <dbaron> xiaochengh: This one keyword proposal can hopefully solve this.<br> <dbaron> Rossen: I see a conversation back and forth between Jonathan and Lawrence on the issue. Jonathan is raising some points -- not sure they've been answered, especially his first point about what is truly critical.<br> <chrishtr> q+<br> <dbaron> s/Lawrence/Laurence/<br> <dbaron> s/descriptior/descriptor/<br> <Rossen_> q?<br> <Rossen_> ack chrishtr<br> <dbaron> chrishtr: regarding critical -- there are examples in issue of font use cases that would be considered critical. This isn't a question about why they'd be served from a 3d party domain if they were critical. If you want your site to be fast you'd ideally serve from same domain, but many sites use 3d party f ont service to serve fonts, which allows 3d party font service to update fonts over time.<br> <dbaron> chrishtr: xiaochengh is proposing that critical fonts should be loaded only if they're truly critical. Hope that font providers could have query parameter so that their stylesheet could say it's render blocking.<br> <dbaron> Rossen_: Jonathan...?<br> <dbaron> jfkthame: Don't have anything specific to add... was trying to understand goals and how it would work. I have a little reluctance to complicate font-display ... already fairly complex that few people understand. But I haven't tried to think through implementation issues.<br> <dbaron> jfkthame: ... of the new critical value.<br> <dbaron> jfkthame: Other question is how this relates to font loading api. Are these use cases where authors should be using font loading api to more closely cnotrol what is happening? Not sure...<br> <Rossen_> ack fantasai<br> <xiaochengh> q+<br> <astearns> q+<br> <dbaron> fantasai: My concern is that it prevents the page from showing text. I understand thatintent is that authors not use it for most of the text, but I think authors might use it for that. We normally don't make it easier to prevent the page from loading for long periods of time, perhaps forever.<br> <Rossen_> ack xiaochengh<br> <dbaron> xiaochengh: problem is developers are already trying to block render of page with various hacks. One example is to add empty external stylesheet that blocks rendering so font can load. Other is add display:none or visibility:hidden and remove when font is loaded. Since developers are already trying to do it, we can provide a better way.<br> <chrishtr> also, style sheets and scripts already block rendering, potentially indefintely.<br> <chrishtr> this attribute also indicates intent directly, and allows the UA to ignore it after a timeout<br> <dbaron> fantasai: I think technique of using visibility:Hidden and then visible is the developer very clearly saying that it's not to be rendered until font loads. Very clear they want invisible.<br> <emilio> q+<br> <dbaron> xiaochengh: not just making element invisible... making entire page invisible.<br> <dbaron> Rossen_: This is use-case specific. People can do it in a more targeted way.<br> <Rossen_> ack astearns<br> <plinss> q+<br> <fantasai> fantasai: my concern is that someone will be like "Oh, my wedding invitation *has* to be loaded in this font because it looks ugly otherwise, so I definitely consider this a critical font" and then the reader of the invitation, on a different connection, ends up never able to read the page<br> <dbaron> astearns: I think I agree with fantasai that the current hacks might be sufficient for this. But I got on queue because of concern with how this works only with style-blocking style sheets. I worry about adding something that will work in some cases but not in others. We'd have to specify what this does, if anything, if the style sheet is not render blocking. And I'm worried about adding something that has that works and doesn't work<br> <dbaron> astearns: characteristic.<br> <dbaron> xiaochengh: The intention is to make it render-blocking but after the document has already started there's no way to block render, so to keep things simple I'm just making it block load of style sheet.<br> <astearns> s/style-blocking/render-blocking/<br> <Rossen_> ack emilio<br> <dbaron> emilio: Similar to that... this would imply the font should load unconditionally and fully -- don't have unicode-range (presumably ignored) -- my other question isn't this more similar to how background images block the load event of the page but not of the style sheet. Doesn't achieve the rendering blocking that you want... but maybe it does? Background image loads get started before layout rather than during layout like fonts.<br> <chrishtr> q+<br> <Rossen_> ack plinss<br> <dbaron> Peter: I agree with fantasai. I hear the argument that authors do this so we should make it easy. That argument falls down when authors are doing something bad -- we have no obligation to do that. We should teach authors how to do fallbacks, progressive rendering ,etc.<br> <fantasai> +1 to "don't optimize for making the bad things easy"<br> <dbaron> chrishtr: Peter, I don't think there is a good way to do it right now. Only way to do it causes flashing on load. size-adjust was added but ??. This is a clean solution to this natural problem.<br> <dbaron> Peter: We have to weight harms between flashing and blank content. Look for other alternative rather than blocking?<br> <dbaron> Rossen: Not sure how this isn't creating flashing as well while you're waiting.<br> <dbaron> chrishtr: Shows white.. shouldn't consider that a flash of unstyled content.<br> <dbaron> fantasai: We already have the block keyword that shows white.<br> <Rossen_> q<br> <Rossen_> ack chrishtr<br> <dbaron> chrishtr: The existing keyword shows white only for the text, not the page<br> <dbaron> ?: ... and there's layout shift.<br> <dbaron> Peter: I'd say both preferable to blank page.<br> <dbaron> chrishtr: I think use cases for either.<br> <dbaron> plinss: Authors don't always consider all the factors<br> <dbaron> s/Peter/plinss/g<br> <dbaron> plinss: Doesn't mean we should make it easier... think it will lead to more abuse.<br> <dbaron> Rossen_: I'm hearing a good bit of feedback. So I think we should take this back to the issue and accumulate a little more consensus there before we bring it back for a resolution. Also given how many people missing today.<br> <fantasai> If we're adding a keyword for this, it needs to be something really obnoxious and obvious, like "block-entire-page-load-forever"<br> <dbaron> Rossen_: Anything else you wanted to highlight today, xiaochengh?<br> <dbaron> xiaochengh: The intention is not to help authors do bad things... let me outline this another way. We're trying to help authors make a tradeoff more easily... tradeoff between page stability and responsiveness. No easy way to go to one end of the tradeoff.<br> <dbaron> Rossen_: We'd like to move it back to the issues.<br> <astearns> I don’t think this is necessarily a bad thing, but I am not convinced there is no current way to achieve an appropriate result<br> <dbaron> fantasai: My understanding is that the proposal is to add a keyword that blocks the page rendering *literally forever* if the font doesn't load. If it's still not loading 30 seconds later because the font isn't loading, that's a problem.<br> <fantasai> s/problem/problem for the user/<br> <dbaron> plinss: I think the concern is that authors will unknowingly use this badly and wind up doing bad things by accident.<br> <tantek> +1 fantasai, plinss this makes it too easy for authors to do *harmful* things to users<br> <florian> +1 to not linking this, for the reasons said by fantasai and plinss<br> <emilio> one could make a case that the same can effectively already happen for any stylesheet tho<br> <chrishtr> Fantasai: this is not new, style sheets can and do already block rendering. I do think the spec for this should say the UA should provide a timeout.<br> <florian> s/linking/liking/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7271#issuecomment-1130233613 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 16:29:52 UTC