fix(nav): sit the logo mark's dot on L's own baseline - #39
Merged
Conversation
…aseline Real bug, reported after #37 shipped: the "." visibly floated above "L"'s bottom edge instead of resting on it. My own earlier Playwright measurements had already caught this (dot bottom 6px above L's bottom at rest) but I mis-scoped the check to "do these two elements' lines merely overlap", which a 4-6px gap still satisfies, and dismissed it as imperceptible without looking at the actual number. Root cause: `inline-block` defaults to `vertical-align: baseline`, which aligns the dot SPAN's own baseline to L's text baseline. Per spec, once `overflow-hidden` is set (needed for the width-collapse animation from #37), an inline-block's own baseline becomes its bottom margin edge rather than its content's text baseline - so the dot's BOX bottom was landing at L's baseline, not at L's own visible bottom. Measured directly (not eyeballed): 4-6px of gap depending on the icon's current font size (13-20px across the scroll range). `align-text-bottom` aligns to the bottom of the parent's font instead of the dot's own computed baseline, landing exactly on L's bottom - measured 0.00px of gap at every font size the icon uses, with a small (<1.3px) residual only under full rotation, which is an axis-aligned-bounding-box measurement artifact of rotating the box, not a real misalignment: it appears in the screen-space rect of both L and the dot equally. The test added in #38 could not have caught this: its overlap check is a much weaker property than "sits on the same baseline". Replaced it with a strict sub-1.5px baseline check (`sitsOnBaseline`), which would have failed against the pre-fix code and now passes against this fix - measured directly on the built output before committing, not just on the reasoning above.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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 real bug
Reported after #37 shipped: the "." visibly floated above "L"'s bottom edge instead of resting on it. My own Playwright measurements from #37's investigation had already caught this — dot bottom 6px above L's bottom, at rest — but I mis-scoped the check to "do these two elements' lines merely overlap", which a 4-6px gap still satisfies, and dismissed the number as imperceptible without actually looking at what it meant visually. It wasn't imperceptible; it was a real, visible gap.
Root cause
inline-blockdefaults tovertical-align: baseline. Per spec, onceoverflow-hiddenis set on an inline-block (needed here for the width-collapse animation from #37), its own baseline becomes its bottom margin edge instead of its content's text baseline. So the dot span's box bottom was landing at L's text baseline — not at L's own visible bottom, since a period glyph's ink normally sits at/near the baseline itself while the span's box extends further up.Measured directly (not eyeballed): 4-6px of gap depending on the icon's current font size (13-20px across the scroll range).
Fix
align-text-bottom(vertical-align: text-bottom) aligns to the bottom of the parent's font instead of the dot's own computed baseline:baseline(before)bottom-0.2em(magic number)text-bottomConfirmed 0.00px at every font size the icon actually uses (13px, 16px, 20px) — not just at rest. A tiny residual (<1.3px) appears only under full rotation, which is an axis-aligned-bounding-box measurement artifact of rotating the box (it shows up equally in both L's and the dot's screen-space rects), not a real misalignment.
Test
The e2e test from #38 could not have caught this — its
overlapsSameLinecheck is a much weaker property than "sits on the same baseline"; a 4-6px gap still overlaps a ~20px-tall dot span. Replaced it withsitsOnBaseline, a strict sub-1.5px check ondotBottomvs.lBottom, verified against the pre-fix code (fails, as expected) and the fix (passes, measured on the actual built output before committing).Stress-tested 8 consecutive runs across chromium/mobile-chromium/mobile-webkit — zero flakes.
Verification
typecheck,lint,content-lintall cleanHeads up on CI
Same caveat as #35/#37/#38:
main'sverifygate has intermittent pre-existing failures (a sitewide WCAG regression, and a flaky total-blocking-time budget) unrelated to any of these nav diffs. If still present, the same bypass situation may apply.