Comments on the font-features explainer

[yoavweiss]

Hey Daniel!

A few random comments about the explainer:

• For Font Features, I'd just say they are "Client Hints" and not "User Agent Client Hints"
• I don't think that font features should be used as critical client hints in most cases:
  • When the CSS is external, it's the CSS that you want to receive the hint, not the HTML
  • When the CSS is inlined, there's some room to consider declaring the hints as critical, but the cost of an initial RTT may outweigh the cost of sending a slightly less optimal font, so the criticallity of the fonts seems like something that should be pending on e.g. ACCEPT_CH frame support at the protocol level.
• Why are prefers-color-scheme and prefers-reduced-motion likely to impact font resources? Also, prefers-color-scheme is shipped in Chromium as a CH
• "The two major kinds of negative impacts involve the initial delay in rendering while waiting for required font files to be downloaded, and the subsequent redraws that might result when font changes require changes to page layout." - that sentence feels out of place, and also those are 2 problems that won't be fully addressed by your proposal (even if they can be improved)
• "responsive images" seem unrelated to fonts
• UA knowledge that's based on the UA's significant version is not going away, and there's no particular need to create hints for (e.g. stale-while-revalidate, unicode-range and preconnect support, that you mention)

Cheers :)
Yoav

[dlaliberte]

Thanks for your comments.

• For Font Features, I'd just say they are "Client Hints" and not "User Agent Client Hints"

OK, done.

• I don't think that font features should be used as critical client hints in most cases:

  • When the CSS is external, it's the CSS that you want to receive the hint, not the HTML

I assume you mean that the request for external CSS would include the hint. But can requests for CSS have critical hints? It sounds like, from your second bullet, that there is either no point, or it is not possible. I am probably missing something critical about critical hints.

• When the CSS is inlined, there's some room to consider declaring the hints as critical, but the cost of an initial RTT may outweigh the cost of sending a slightly less optimal font, so the criticallity of the fonts seems like something that should be pending on e.g. ACCEPT_CH frame support at the protocol level.

OK, I am changing the text to say "These client hints may be used as critical client hints". Or we may decide to remove the mention of critical hints if there is no reasonable possibility for them.

• Why are prefers-color-scheme and prefers-reduced-motion likely to impact font resources? Also, prefers-color-scheme is shipped in Chromium as a CH

I don't know. I think this is a left-over from copy-pasting from another client hints doc. Deleting for now.

• "The two major kinds of negative impacts involve the initial delay in rendering while waiting for required font files to be downloaded, and the subsequent redraws that might result when font changes require changes to page layout." - that sentence feels out of place, and also those are 2 problems that won't be fully addressed by your proposal (even if they can be improved)

This text is redundant with the list of goals stated just before this. But I don't understand why the font feature client hints won't address these goals fully. Is it enough to partially address them? How would we fail?

• "responsive images" seem unrelated to fonts

I don't recall where that came from. Deleting.

Only connection I can think of is glyph-like svg images used in an inline text context.

• UA knowledge that's based on the UA's significant version is not going away, and there's no particular need to create hints for (e.g. stale-while-revalidate, unicode-range and preconnect support, that you mention)

That was from Rod Sheeter (@rsheeter). Let's ask him.

[yoavweiss]

I assume you mean that the request for external CSS would include the hint. But can requests for CSS have critical hints? It sounds like, from your second bullet, that there is either no point, or it is not possible. I am probably missing something critical about critical hints.

Critical hints are indeed intended for the navigation request, which is the first request hitting the origin. Since you can navigate to a CSS file, the requests for them go out later, after the Client Hint opt-in was well-received, even without Critical-CH.

This text is redundant with the list of goals stated just before this. But I don't understand why the font feature client hints won't address these goals fully. Is it enough to partially address them? How would we fail?

Font files would still be downloaded, it's just that with the right CH in place, we'd download the optimal font files. But there would still be a delay until the fonts arrive, and if layout happens before that, a potential layout shift as a result of font rendering.

[dlaliberte]

A CSS file can have an @import rule which results in a request for a second CSS file. So the server could return something different in this second CSS file depending on client hints. The @import rule can be conditional, so some decisions can be made in the client after loading the first CSS and before subsequent loads.

For web pages that dynamically request more content to display on the same page, there is more opportunity for optimizing each subsequent response. Maybe fonts don't typically change much in this scenario.

If the client is able to anticipate the size of each character in a font that is still to be loaded, that means the initial rendering of content before the font has been loaded can be maintained with the same layout after the font is loaded. And if the server knows this is possible in the first place, with a Critical-CH in the first request, then this could significantly change what it responds with.

That's my speculation anyway. I might be totally wrong about all this. Let me know.

[yoavweiss]

A CSS file can have an @import rule which results in a request for a second CSS file. So the server could return something different in this second CSS file depending on client hints.

CSS can indeed trigger further requests, but it's never the first navigational request. So by the time the browser requests the first CSS, the server already had an opportunity to deliver an Accept-CH header.