- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 22 May 2015 10:18:44 -0700
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style <www-style@w3.org>
On Thu, May 21, 2015 at 5:56 AM, John Daggett <jdaggett@mozilla.com> wrote: > During the past two days at the CSSWG F2F there were two discussions of > how to control the display of downloadable fonts while fonts are > loading. See below for the IRC log of the discussion from both days. > > There were two resolutions, I've summarized these with a rough sketch of > spec text. > > 1. Control is an @font-face rule descriptor, not a property > > 2. Values are as defined below, with the exact value names to > be worked out later: > > font-loading-display: block | swap | fallback | optional > > Value definition (with my alternate value names): > > block (show-blank) > > For text content that uses a currently loading font resource, > initially display text transparently using some form of fallback > font. If the font is still unavailable 3s later, display using the > fallback font. After the font resource is loaded, display text > using the font resource. > > swap (show-fallback) > > For text content that uses a currently loading font resource, > immediately display text using a fallback font instead (i.e. the > font that would be used if the font resource was unavailable). > After the font resource is loaded, display text using the font > resource. > > fallback (conditional) > > For text content that uses a currently loading font resource, > immediately display text using a fallback font instead (i.e. the > font that would be used if the font resource was unavailable). > If the font resource is loaded within 3s from the time the load > begins, display text using the font resource. Otherwise, leave the > text as it is, displayed in the fallback font. > > optional (conditional local) > > For text content that uses a currently loading font resource, > display text using font resource if it loads from cache (very > short timeout), otherwise use the fallback font instead. The > 'optional' value allows UA to not continue loading the font > for the next time. > > Note: the 'optional' value was not sufficiently defined in the minutes, > see below. > > Using a timeline to compare these values, we have: > > block: > blank ==> load within 3000ms ==> font > blank ==> load after 3000ms ==> fallback ==> font > > swap: > fallback ==> font > > fallback: > fallback ==> load within 3000ms ==> font > fallback ==> load after 3000ms ==> fallback (no change) > > optional: > fallback(?) ==> load within 100ms ==> font > fallback(?) ==> load after 100ms ==> fallback (no change) > > Issues: > > * Is there an 'auto' value here that allows user agents to define the > default behavior? Or the default value is...? Yes, there's an "auto" value. All the proposals so far have included one, it just wasn't interesting to talk about in the meeting, so wasn't included. > * The conditional display values, 'fallback' and 'optional', need a lot > more details defined. I don't see how "fallback" needs any more details. You seem to have described it just fine, above. block/swap/fallback are all easily describable with the concepts of "blank period" followed by a "swap period" followed by just giving up and marking the font as failed for the rest of the page's lifetime; they just vary on what (possibly infinite) duration to assign to the first two periods. "block" is ~3s/infinite, "swap" is 0s/infinite, "fallback" is 0s/~3s. > For 'optional', during the epsilon period when > fonts are pulled out of the cache, is blank or fallback text > displayed? I think blank text makes more sense. I don't have a strong opinion on this. If you do start painting before the epsilon expires, doing blank vs fallback won't have any effect on flicker (blank is painted with the fallback's geometry). On the other hand, it's only for an epsilon, so the downside of blank text is pretty darned small, and probably overridden by the downside of a FOUT when the font is retrieved successfully. > Are font loads after > the timeout aborted? Can user agents skip the load given network > conditions (e.g. networks with known max bandwidth)? This was discussed; it'll be up to the UA, which can use whatever knowledge it has of the ambient network conditions to make this choice. I plan to have very explicit language in the spec that this value might mean the font is not used at all for some users. > If the font loads > can be aborted/skipped, the 'optional' value is equivalent to > disabling the use of this font across *all* pages. This would be the > same as authors simply not using fonts for low-bandwidth situations -- > is this really the right way for authors to express this?!? It seems like a pretty reasonable way to express it, imo. Do you have better suggestions? What are your reservations with this approach? > * As defined, I think the 'optional' value is what Florian was > advocating for but I don't think it's what some of the original Google > folks wanted. When this value was first described to me it was > presented as "we don't ever want to see a flash of anything" value, > such that fonts are either available or not and there's no second > reflow of text. I think the intended use case was for very > perf-sensitive pages. Yes, this is roughly what Florian was outlining. I'll verify with our folks that this approach matches our desires, but I'm pretty sure it does. > * The use of timeouts based on the timing of resource loads does not seem > like > the right approach for author controlled behavior. The implicit font > loading behavior of @font-face fonts means that they usually are > queued up behind other resources on the page. The more resources on > the page the longer it will be until those font loads start. I think > an author-defined control should be based on timeouts correlated with > the user-perceived page load time. For example, time since > navigationStart. I think this is actually closer to the behavior that > several CSSWG members seem to be advocating. I'm not a fan of this. It means that fonts which aren't even used at initial page load are basically immediately penalized. This feels like a bad behavior, and also doesn't match current behavior. If this was *paired with* a preloading hint, I'd be comfortable with starting the timer from the time the hint is seen, or something similar. But by itself, with font loads triggered by use, I'm not a fan. > * I think there's a big potential for the conditional display values, > 'fallback' > and 'optional', to produce ransom note effects with common usage > scenarios. Fonts are used as families, not simply as single faces. If > a page uses a combination of regular, bold and italic faces, timeouts > with some of these individual faces will produce text displaying in > a mixture of fonts (e.g. bold text in the downloadable font, regular > text in the fallback font). Ooh, good point. Perhaps we should tie the behavior together for a given family: if any part of the family displays, it should swap in the rest regardless. > * I really think this needs to be implemented in conjunction with some form > of > preload hint, since the late loading behavior of fonts is a major > reason authors are asking to control behavior during the page > load phase. The control we're discussing here is only half the > solution. I'm not opposed to that *as well*. Alternately, we can just lean on script for this; it's super-simple to kick off a .load() on the fonts you need right away, and thus start their timers. > * Another concern I have is that I'm not sure how interoperable these values > will be in practice. Browser implementations such as iOS Safari are > relatively conservative about the number of times a given element is > reflowed during the loading process. The natural process of coalescing > reflows will have the effect of increasing the perceived timeouts > associated with downloaded fonts. The more conservative the browser is, > the > longer the timeout will end up being. Sure, but I doubt this'll end up being a huge difference in practice. > Comments: > > While I understand the use case for the conditional values, I think > their use in practice will be problematic. That was the reason I was > advocating during the Tuesday discussion that we leave this > functionality to authors using script, at least for the initial version. > Based on the conditions that script users come up with, we can then > attempt to mimic those values in new values for font-loading-display. The WG was convinced that we can define useful values right now; authors can always come up with their own behavior, but it didn't seem sufficiently controversial or difficult to define some basic behaviors now. > I don't really see a need for the 'swap' value. Interesting, because it's the one that came from your proposal. ^_^ (You called it "fallback", but the WG and I agreed that "swap" was better for your "always swap" behavior and "fallback" for my "only swap for a limited time" behavior.) > I would prefer to have > the "show blank text initially" value take some sort of short/long > modifier, as Florian suggested before. The "short" modifier would be > very close to 'swap' but the flash of fallback would happen less if you > give it a small "show blank text" period. Similarly, the current > proposal eliminates the value for authors that want something closer to > current Safari behavior. I think allowing a longer timeout for font > resources that are really required is important. I'm fine with considering an epsilon blank period for the "swap" value. I'll add an issue to the draft and ask for implementation experience to help settle the issue when I update the spec today. ~TJ
Received on Friday, 22 May 2015 17:19:32 UTC