Change:
~~~~~~~~{.ebnf .gram} if_expr : "if" expr '{' block '}' [ "else" else_tail ] ? ; else_tail : "else" [ if_expr | '{' block '} ] ; ~~~~~~~~

Discussion:
Changing default font size from 16 to 17 on Firefox makes page to render oddly. ! !
Same behavior in Chrome too if you change the Font Size setting to anything higher then "medium"
That might be related to , which changed our font sizes from (absolute) to (relative to the user's font size). I don't see how that could produce the symptoms you're seeing, but it's related to font sizes. Do you see this on all crates, or just recently built crates?
Indeed, this seems to only happens on newer crates. Even older version of a crate in problem will display properly, but the most recent one has the problem(ex: is fine, but has the problem.
A little quick investigation shows this is because the element is in a flexbox alongside the sidebar, and the browser is choosing to shrink it from its default size (but seemingly only when the font size is bigger than default?). Setting on seems to fix, but I'm not sure that's the correct solution.
Also, unchecking the rule (or setting it to seems to do the trick.
in your (thanks for that!), you had: Do you happen to remember why you set min-width: 0?
Yeah I agree, I don't think that's the proper fix. I don't quite remember but I think it was because flex child elements have defaulted to auto that caused the child to overflow the parent. But I don't think that's the proper fix here. If we look at the flex container: ! We can see that the flexbox container isn't utilizing the whole width (because it hasn't been set!). So perhaps the proper fix would be to make the flex container ? (I've tested it locally and it seems to work just fine)
I propose ~closing this in favor of (or moving this issue to the rust repo if that's possible?).
transferred
The thing you posted works, but it's unsatisfying. If the issue is lack of an explicit , why does this only show up on font sizes 16px? Here's another possible fix: set on . The page was previously inheriting from rustdoc's CSS, which sets that on . When rustdoc's CSS changes to (i.e. respect what the user set), that also affected the font size in the topbar.

Since the topbar has a fixed height of 33px, this caused some of the elements to overflow the topbar, at which point they interfered with 's ability to automatically grow as far as it needed. What I like about this solution is it doesn't layer tweaks on top of tweaks. Instead, it's adding back in something explicit that was implicitly depending on, but that it shouldn't have been.
This is fixed in rust-
Since this fix won't retroactively apply to old docs, if anyone else runs into this thread, here's a ublock origin filter that has worked for me: (Coincidentally it uses the same hack-fix as cynecx mentioned) I should note that I observe this issue for non-font reasons (I believe, inspector could be lying to me about font calculations) due to the fact I always view docs in a vertical window (half split (left/right) of a 1080p monitor). And here's also an untested attempt at using built-in firefox userstyles: () And if you want to check if it works, which is affected. Edit: I should note that my issue isn't fixed by the font fix (which I believe(?) is present on the latest crate builds), but I didn't actually find much useful info to recreate. It could be an issue with desktop vs mobile detection CSS rules or something similar as that tends to be the issue (sites not supporting vertical desktop view is frustratingly common, unfortunately). All I've got is that it's firefox only. I can make an issue if someone lets me know what the preferred repo for such an issue would be.