fix(v2): reaction counts rode high next to the emoji — align ink, not boxes - #867
Merged
Conversation
… boxes Reported by Sam during YC-interview prep with an HQ screenshot: on desktop, the count digit sits visibly above the emoji's center; mobile renders fine. Root cause is a measurement trap worth recording. The chip flex-centers its two spans, and the spans' LAYOUT boxes are perfectly centered — probed live with getBoundingClientRect: 0.00px offset, while the bug sat in plain sight. Apple Color Emoji ink extends below the baseline; digit ink does not. Box centering therefore diverges from ink centering by a couple of pixels on desktop, in exactly the direction the screenshot shows. The instrument measured the box; users see the ink. Fix is two lines, exact by construction rather than by nudged constants: align-items: baseline on the chip (digits hang on the emoji's baseline — how "emoji + digit" renders in plain inline text, the reference that looks right on every platform), and line-height: 22px (chip inner height) on the emoji span, which becomes the sole vertical centering of the shared line. Verified visually in-browser at 3x zoom, current vs fixed side by side; chip geometry (24px pill) unchanged. Fixture-path block gets the same alignment for parity. Guarded in v2-layout-invariants (both halves are load-bearing and invisible to jsdom): baseline on the button rule, 22px on the emoji span — shrink either and the pair top-hugs the chip or the count rides high again.
This was referenced Aug 6, 2026
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.
Closes the desktop half of #865 (Sam's HQ screenshot: count digit visibly above the emoji's center; mobile fine).
The measurement trap, for the record
The chip flex-centers its two spans, and the spans' layout boxes are perfectly centered — probed live with
getBoundingClientRect: 0.00px offset on every chip, while the bug sat in plain sight. Apple Color Emoji ink extends below the baseline; digit ink does not, so box centering diverges from ink centering by a couple of pixels on desktop. The instrument measured the box; users see the ink. (Same lesson as the layout-invariants rule one layer down: verify what users see, not what the DOM reports.)The fix — exact by construction, no nudged constants
align-items: baselineon the chip: digits hang on the emoji's baseline, which is how "👍 2" renders in plain inline text — the reference that looks right on every platform (and why mobile was already fine).line-height: 22px(chip inner height) on the emoji span — with baseline on, this line box is the only thing vertically centering the pair; that's documented inline because shrinking it back to 1 top-hugs the chip.Verified visually in-browser, current vs fixed side by side at 3× zoom: current reproduces the screenshot, fixed sits both glyphs on one baseline, chip geometry (24px pill) unchanged.
Guard
Added to
v2-layout-invariants— both halves are load-bearing and invisible to jsdom. 21/21 invariants green; V2MessageBubble suite green.Remaining in #865, deliberately untouched tonight: the triple
.v2-msg__reactiondefinition cleanup (the "dead" block contributes the hover transition) and reactions being absent from the public read-only showcase view entirely.