Repository navigation
Keep the hero wash inside the screen on phones - #206
Merged
Merged
Conversation
The band's decorative corner wash is a radial gradient from the top-left, fading out at a fixed 24-26rem depending on theme and page. That is 384-416px -- wider than a 375px phone -- so on a phone the falloff never completed before the right edge. Instead of a corner accent the whole band read as tinted, ending in a hard edge that looked like the gradient had been cut off. Capped at 70vw as well, which puts the fade at 263px on a 375px screen. min() leaves desktop untouched: above about 560px the rem value is always the smaller of the two, and it still resolves to 400px at 1400. All four declarations, both themes and both the docs shell and the chrome consistency pass, since they had drifted to four slightly different radii.
It never painted. 11-docs-chrome-consistency.css redeclares every property of it -- content, position, inset, z-index and both gradients -- with a selector list that is a superset of this one, and loads later. Confirmed by measuring: the computed ::before background is byte-identical before and after this deletion, in both themes. Both copies had drifted to different opacities, angles and radii, so it was not the same wash declared twice; it was a second wash that could never be seen. The previous commit had to edit both, which is how it surfaced. This also puts 03-shell-layout-base.css back under the 300-line guard, which the added comment had pushed it over. Trimming the comment would have been the wrong fix -- the file was over because it was carrying a rule that does nothing.
Sticky. The contents bar is declared sticky and never stuck, because overflow-x: hidden on <body> and .main-frame computes the other axis to auto and makes each of them a scroll container. The document is what scrolls, so the sticky element had a scrollport that never moved. Both are overflow-x: clip now, which contains the same horizontal overflow without creating a scroll container. The bar pins at 102px, under the header and the section bar that are already fixed, and the hero scrolls away as before. Current-item marker, three menus, two causes. A rule in 24 and 28 flattened every aria-current link under .right-sidebar to no border. It was written for the contents rail, but PageSidebar renders the mobile section dropdown inside .right-sidebar too, so the current page was the only entry there with no border at all -- every other entry reserves 2px for one. Narrowed to exclude both dropdowns. In 22, the reset for the contents dropdown listed every state including aria-current, so the heading you are reading looked like the rest. Restricted to the resting and hover states, with the current one given the marker back. Also deletes four rules keyed on .mobile-toc-trigger, .mobile-docs-trigger, .mobile-docs-bar and .mobile-toc-bar. None of those classes is emitted by any component -- they appear only inside the stylesheet, never on an element -- so the rules could not have applied to anything. That is what put 28 back under the 300-line guard, which the comments above had pushed it over.
fstubner
force-pushed
the
fix/hero-wash-scale
branch
from
August 18, 2026 21:49
2d15d02 to
b07f6e4
Compare
The comment claimed the doubled class was needed because the bundler does not emit these files in filename order. Measured on the production build: 30 is emitted after 20, and the rule it competes with carries no !important, so these rules win on either count. The doubled class was never doing anything; removed, and verified the rails and the active marker still render. Emission order genuinely is not always filename order -- 24 is emitted before 23 in the same build -- but that is not what was happening here. The symptom that prompted the workaround was a stale deployed stylesheet, which had already caused two false readings earlier the same day.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The docs hero band has a decorative corner wash — a radial gradient from the top-left, fading out at a fixed 24-26rem. That is 384-416px, wider than a 375px phone, so on a phone the falloff never completed before the right edge: the whole band read as tinted and ended in a hard edge that looked like the gradient had been cut off rather than finished.
Capping the radius at
70vwas well puts the fade at 263px on a 375px screen.min()leaves desktop untouched — above about 560px the rem value is always the smaller of the two, and it still resolves to 400px at 1400.Applied to all four declarations (both themes, both the docs shell and the chrome-consistency pass), which had drifted to four slightly different radii.
Verified at 375 and 1400; a11y gate clean in both themes.