-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unblock font loading in rustdoc.css #72092
Conversation
rustdoc's font loading defaults to "auto", so browsers may block render. But rustdoc's case prefers a faster TTI for scrolling, this means the strictest font-display in use should be "swap". rustdoc's fonts do provide notable legibility improvements but first-time users will have little trouble reading without. This means "optional" is preferred. The one exception is Source Serif Pro: it's a big difference for body text, so "fallback" is preferred over "optional" to cause a (tiny) block.
Thanks for the PR! Looks good to me, but before confirming, just a few questions: it first renders the page with the default system font I assume and once the font is loaded, it makes the switch, right? In my low level of understanding, it seems like it actually performs more operations and should be slower, but just to confirm: it's faster this way? If "yes" is the answer to both questions, then it's good for me! :) |
The time till you first see text is shorter. "optional" lets the user-agent decide if downloading the font is even necessary. Otherwise "swap" would be an alternative. |
Yes† and Yes. According to the draft spec and other docs I can find, it appears that most browsers implement a default behavior of beginning to render text anyways (invisibly) and then rerendering the text with the appropriate font once the font is loaded. So browsers just do a lot of ops anyways. These changes speed things up by allowing the browser to not render text twice if the fonts cannot be obtained for that initial rendering pass. For I would not recommend On the second visit to a rustdoc page, however, the fonts should already be in cache, so they should load and render instantly. Unless the user is somehow accessing rustdoc webpages on an electronic potato that somehow has a browser installed, in which case the same logic applies. |
Fine by me then, thanks! @bors: r+ rollup |
📌 Commit 510fce1 has been approved by |
…Gomez Unblock font loading in rustdoc.css rustdoc's font loading defaults to "auto", so browsers may block render. But rustdoc's case prefers a faster TTI for scrolling, this means the strictest font-display in use should be "swap". rustdoc's fonts do provide notable legibility improvements but first-time users will have little trouble reading without. This means "optional" is preferred. The one exception is Source Serif Pro: it's a big difference for body text, so "fallback" is preferred over "optional" to cause a (tiny) block. This follows up on (but does not resolve) rust-lang#20962, taking PageSpeed Insight's rec fairly directly. Supporting reading material: https://drafts.csswg.org/css-fonts-4/#font-display-desc
Rollup of 5 pull requests Successful merges: - rust-lang#71618 (Preserve substitutions when making trait obligations for suggestions) - rust-lang#72092 (Unblock font loading in rustdoc.css) - rust-lang#72400 (Add missing ASM arena declarations to librustc_middle) - rust-lang#72489 (Fix ice-72487) - rust-lang#72502 (fix discriminant type in generator transform) Failed merges: r? @ghost
…changes, r=Dylan-DPC Remove font-display settings Since for the moment, the result isn't as expected since rust-lang#72092 when not using docs locally, let's revert them. r? @Dylan-DPC
rustdoc's font loading defaults to "auto", so browsers may block render.
But rustdoc's case prefers a faster TTI for scrolling, this means the
strictest font-display in use should be "swap". rustdoc's fonts do provide
notable legibility improvements but first-time users will have little trouble
reading without. This means "optional" is preferred.
The one exception is Source Serif Pro: it's a big difference for body text, so
"fallback" is preferred over "optional" to cause a (tiny) block.
This follows up on (but does not resolve) #20962, taking PageSpeed Insight's rec fairly directly. Supporting reading material: https://drafts.csswg.org/css-fonts-4/#font-display-desc