- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 18:13:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `font-display`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: font-display<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4108<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4108<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4108<br> <fantasai> TabAtkins: When I originally drafted the font-display values, the last one, optional, I intended to be as much as possible "make the user's experience smooth even if they don't get pretty fonts"<br> <fantasai> TabAtkins: Wasn't super clear in the spec, and implementers came up with answers that don't satisfy that goal<br> <fantasai> TabAtkins: Within first 100ms or less, still creates a layout jump<br> <fantasai> TabAtkins: Jake was running into the same problem<br> <fantasai> TabAtkins: wanted smooth page display without any layout jank, and wasn't getting it<br> <fantasai> TabAtkins: I believe the current text addresses it, perhaps with an extra comment<br> <fantasai> TabAtkins: Would like some discussion from y'all<br> <TabAtkins> https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-display-optional<br> <fantasai> TabAtkins: My text atm, if font can be loaded "immediately", can be used, otherwise ignore it<br> <fantasai> TabAtkins: can't be used for the rest of the page's lifetime. Refresh page, can try again<br> <fantasai> TabAtkins: Paried with some additional info<br> <fantasai> TabAtkins: MUSTNOT cause the layout of the page to jump<br> <fantasai> TabAtkins: allowed to delay initial rendering if needed to load the font<br> <fantasai> TabAtkins: specifically, we have some issues wrt how to do in Chrome, can put more detail in the spec<br> <fantasai> TabAtkins: Anyone have comments on details?<br> <fantasai> TabAtkins: If in memory cache for tab, use the font. Otherwise we go to disk, takes too long, skip it<br> <fantasai> TabAtkins: Once loaded, may ro may not be present for future navigation depending on cache state<br> <fantasai> TabAtkins: Cannot depend on font ever being there<br> <fantasai> TabAtkins: Want to make sure that all font pre-loads bring the font into the memcache<br> <fantasai> TabAtkins: track which fonts are there<br> <fantasai> TabAtkins: When preloaded font is optional, delay loading to give time to get off disk -- or extremely fastnetwork<br> <fantasai> TabAtkins: otherwise, don't delay<br> <fantasai> TabAtkins: If you don't do anything special on your page, just say font is optional<br> <fantasai> TabAtkins: almost guaranteed to not have font on first page load<br> <fantasai> TabAtkins: chance of available on future page loads, but not guaranteeed, e.g. if on device with small cache<br> <fantasai> TabAtkins: If it's a preloaded font, then very likely to be load on future navigations because we will delay rendering to load into memory cache<br> <heycam> q+<br> <fantasai> s/small cache/small memory/<br> <fantasai> TabAtkins: because preloading is a hin that something is important enough to kick of load asap<br> <fantasai> TabAtkins: That seems to satisfy the use cases for optional that we want to hit<br> <fantasai> TabAtkins: allowing pl to have completely jank-free font-optional experience<br> <fantasai> TabAtkins: Try your best to use it, but prioritize no jank<br> <myles> q+<br> <astearns> ack heycam<br> <fantasai> heycam: not sure how much is normative vs heuristics<br> <fantasai> heycam: but seems a bit weird to me that you have two different behaviors wrt disk cache<br> <fantasai> heycam: without preloaded fonts, disk cache is deemed too slow, but link rel=preload it's ok?<br> <fantasai> TabAtkins: Not so much it's too slow, but don't want to incur cost of delaying rendering unless indication that it's important to you<br> <fantasai> heycam: is this because checking whether the font is in the disk cache is also slow? is it the checking, not the loading?<br> <fantasai> TabAtkins: in our implementation, memcache check is fast enough to be synchronous, whereas disk cache is async, we kick off without loading<br> <fantasai> heycam: disk cache can be very fast when it's not too big<br> <fantasai> TabAtkins: definitely cool to keep things vague enough that UAs can adjust<br> <fantasai> TabAtkins: but want preload to cause delay<br> <fantasai> heycam: Other thing I was going to say is I'm not really a big fan of optional<br> <fremy> q?<br> <astearns> ack myles<br> <fantasai> myles: I have a lot to say so split into pieces<br> <fantasai> myles: Firstly, wnat to make sure it's clear that WebKit will never ever defer first load. So that has to be not a case. that's our philosophy<br> <fantasai> myles: Can you be super clear about which, you listed like 3 main pieces<br> <fantasai> myles: one is deleted number 100ms and replaced with words<br> <fantasai> myles: one is never cause layout jank<br> <fantasai> myles: last one was about preloading<br> <fantasai> myles: which are normative<br> <fantasai> TabAtkins: first two are normative, in the spec<br> <fantasai> TabAtkins: third one I would like to put in the spec<br> <fantasai> myles: The spec shouldn't use words mem cache and disk cache, those are impl details<br> <fantasai> myles: still not guaranteed to get the font even if preload<br> <fantasai> myles: there's nothing testable here<br> <fantasai> myles: So I think this should be evangelism, not in a spec<br> <fantasai> myles: "for our browser, you will get better results if you preload"<br> <fremy> q+<br> <fantasai> TabAtkins: Talking to internal customers who want no jank on initial load<br> <fantasai> TabAtkins: if they don't get it, and instead block loading page, that's a worse user experience<br> <fantasai> TabAtkins: so having some reasonable assurance of similar behavior among browsers would be worthwhile<br> <fantasai> TabAtkins: ultimately stochastic, cna't depend on it, but difference between 80% and 10%<br> <fantasai> myles: Are your internal customers only considering Chrome, or also other browsers?<br> <fantasai> [unminuted]<br> <fantasai> myles: Other piece I want to mention, dbaron brought up a super valuable point<br> <fantasai> myles: I think it supports what heycam said as is last sentence<br> <fantasai> dbaron: One of my concerns with this is that a lot of stuff around downloadable fonts is designed to deal with the possibility that you have a pretty large number of faces for various reasons<br> <fantasai> dbaron: You might have fonts egmented by character range, multiple weights 4-6 of them, a lot of the mechanisms around downloadable fonts were designed to load lazily<br> <fantasai> dbaron: define a library, fetch the ones you need<br> <fantasai> dbaron: so some of this pre-loading stuff...<br> <fantasai> dbaron: there are cases where you just use one font<br> <fantasai> dbaron: those cases probably bias towards symbol font hacks, and text that is all Latin<br> <fantasai> dbaron: and maybe things are more complicated in non-Latin languages, or things that use more weghts and stuff like that<br> <fantasai> dbaron: one of my big concerns about font-display is that it is per-face<br> <fantasai> dbaron: can have situation where your regular font cached and bold font isn't<br> <fantasai> dbaron: and using downloadable font permanently for regular weight and local font for bold might be worse than all of the other cases<br> <fantasai> TabAtkins: Those can still totally happen is the font load just doesn't occur<br> <fantasai> dbaron: if you have network failures can happen<br> <fantasai> myles: optional makes it more likely that it fails<br> <myles> q_<br> <myles> q+<br> <astearns> ack fremy<br> <fantasai> fremy: As an author, at this point, with current proposal for optional, I would be very unlikely to use it. Because more likely to not get your font than to get it<br> <fantasai> fremy: why bother?<br> <fantasai> fremy: Only if user keeps using your site regularly, not going to be in memory<br> <dbaron> s/other cases/other cases (including flashing, or fallback for all the fonts)/<br> <fantasai> fremy: not unless constantly in use<br> <fantasai> myles: no, it's valuable for web sites while you're navigating through mutiple pages on the site<br> <fantasai> TabAtkins: won't work on single-page app, don't use it in one<br> <AmeliaBR> q+<br> <fantasai> fremy: You're extremely unlikely to get the font, then why bother? You are going to download the font anyway.<br> <fantasai> TabAtkins: Your case is a single-page app that gets closed and reopneed every day<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> TabAtkins: preload signal intention is that, if it's still in your disk cache, it will likely get used the 2nd day and subsequent days, because giving it enough time fo rthat<br> <fantasai> fremy: Safari said they don't want to block rendering<br> <fantasai> myles: Internal clients care that usage gets up to 80%, but we're absolutely not going to block rendering<br> <fantasai> myles: That's not going to work in Safari<br> <fantasai> TabAtkins: assuming ppl aren't using optional, then comfortable with janky 2 frames and then stable layout<br> <fantasai> myles: I'm OK with you've shown the page with fallback font then never show the page with loaded fonts<br> <fantasai> TabAtkins: ...<br> <fantasai> TabAtkins: If it's likely that optional will never give them assurance to see font, then they'll use JS to delay rendering manually<br> <fantasai> TabAtkins: or will use one of the values that wll cause jank anyway<br> <fantasai> myles: This is an intractable problem. We can't never delay rendering and have the disk cache be able to serve tehse requests<br> <fantasai> myles: given that these customers will never get what they're aiming for, I don't think that the association with preloading makes sense<br> <fantasai> TabAtkins: Want to check understanding<br> <fantasai> TabAtkins: website authors using fallback, getting a couple frames in one font and then frames in other font, it's better than getting a few frames of nothing and thn getting the page?<br> <fremy> q+<br> <fantasai> s/thn/then/<br> <myles> q-<br> <astearns> ack AmeliaBR<br> <fantasai> AmeliaBR: I've heard a lot of confusion of what's the purpose of this value<br> <fantasai> AmeliaBR: Tab said the goal was to avoid jank<br> <fantasai> AmeliaBR: If that's the goal then maybe other smarter ways this can happen, like waiting until doing a major repaint anywan and then block in the font<br> <fantasai> AmeliaBR: catches the single-page app update situation<br> <fantasai> AmeliaBR: but I don't kno if that's the best<br> <fantasai> AmeliaBR: As a user, the idea of downloading fonts but then not using them unless I happen to close the page and re=-open it before it gets lost from the cache, that's not a great use of my data plan<br> <fantasai> TabAtkins: UA is allowed to skip downloading if it thinks that's reasonable in the circumstances, and metered data is definitely such a circumstance.<br> <fantasai> astearns: Done for today<br> <fantasai> Meeting closed.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4108#issuecomment-577802886 using your GitHub account
Received on Thursday, 23 January 2020 18:13:06 UTC