[css-fonts-4] Clarify the behavior of the 'very small' block period, …

[tabatkins]

…to resolve #4108.

@litherum Would you mind reviewing? I wasn't sure if you wanted to maintain ownership of the font-display section of the spec, or if it was okay for me to still make edits.

Also @jakearchibald, does this new wording work for you?

[litherum]

This is confusing because it sounds like “no network” describes behavior, but it’s being presented in a context where the term is being presented as a simple duration.

Are you sure this concept isn’t better described as behaviors (like “check the cache but not the network”) instead of simple durations?

[tabatkins]

Hm, I see your point about the naming.

I tried describing the behavior more explicitly first, but since it needs to apply to two values mostly identically, it felt really weird. That said, reviewing this again with fresh hours-later eyes, I'm still not actually addressing Jake's point, which is that we don't want it to render with invisible-fallback at all if that's avoidable (but phrasing in terms of block periods still allows exactly that behavior). I'll take another crack at it tomorrow.

[jakearchibald]

Do we have the concept of "block the rendering" anywhere else? I think we only have parser blocking.

But yeah, it seems worth defining, since it's how font rendering works for all fonts that aren't web fonts.

[tabatkins]

Not explicitly, but I'm comfortable hand-waving about it.

[svgeesus]

@jakearchibald I'm reading your #4370 (comment) as a "changes requested" review, to clarify the issue mentioned by @litherum is that right?

[svgeesus]

pinging @jakearchibald to clarify whether you request changes or not. @litherum I agree with your point. @tabatkins could you reword and if necessary rebase so we can merge this?

[jakearchibald]

Sorry for missing this.

I filed #4108 because browsers have layout instability when using font-display: optional.

"block" in this spec seems to mean "block the rendering of this font". It doesn't seem to mention the rendering of other content that loads afterwards. Right now, when a font is blocked, it's still laid out using the fallback font. Then, the intended font loads, and the page is re-laid out with the metrics of the loaded font. This creates layout instability.

It feels like the solution needs to define a new kind of "block", one that goes beyond the text. It needs to block all further layout until it's had a chance to see if that font is immediately available.

The changes here don't seem to require that kind of layout stability, so I guess I'm requesting changes, yeah.

[jakearchibald]

(but also I'm not really part of this group or familiar with how strictly things should be defined, so if you all think I'm wrong, ignore me)

[tabatkins]

Actually, the changes already made it into the spec, so I should close this PR. ^_^ @jakearchibald, feel free to review https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-display-optional to make sure it matches what you want; I'm pretty sure it does now, tho in a declarative way (requiring no layout shifts and allowing a delay to achieve that) rather than defining what it means to block the rest of layout.