Measure label widths instead of guessing them - #13
Merged
Merged
Conversation
Rows on the axis are assigned from how wide each label is, and the width was a flat 7.2 pixels per character. That number was measured once, against one sans-serif at one size, and then applied to every theme and every headline. Measured against the real thing it was 15-25% too wide across the board -- "The printing press" was estimated at 130px and actually renders at 103. An overestimate does not overlap labels, it wastes rows: the packer pushes neighbours apart that would have fitted, so the stack grows taller than it needs to and the shortest label budget kicks in earlier than it should. Now measured with canvas measureText in the font the labels actually render in, read from a live label so a page theming --bt-font is measured in its own font. Results are cached per string and dropped when the font changes. Also re-lays-out on document.fonts.ready: a web font arriving after first paint changes every width, and without this the layout stays committed to measurements taken in the fallback face. Falls back to the old estimate where canvas is unavailable. Verified in the browser: 13 events over 8 lanes, 0 overlapping labels.
Files the starter issues in one command instead of a dozen browser forms. An empty tracker tells a visitor there is nothing to do here; a dozen scoped issues tells them where to start, and that difference is worth automating so it actually gets done. node scripts/seed-issues.mjs create everything node scripts/seed-issues.mjs --dry-run show what would be created node scripts/seed-issues.mjs --print markdown, to file by hand Creating a label that already exists is treated as success, so the script is safe to re-run.
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
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.
What this changes
Two things.
1. Label widths are measured, not estimated.
Rows on the axis are assigned from how wide each label is, and the width was a
flat 7.2 pixels per character — a number measured once against one sans-serif
at one size, then applied to every theme and every headline.
Measured against the real thing it was 15–25% too wide across the board,
including in the default font:
An overestimate does not overlap labels — it wastes rows. The packer shoves
apart neighbours that would have fitted, so the stack grows taller than it
needs to and the shorter label budget kicks in earlier than it should.
Now measured with
canvas.measureTextin the font the labels actually renderin, read from a live label so a page theming
--bt-fontis measured in its ownfont. Cached per string, dropped when the font changes. Falls back to the old
estimate where canvas is unavailable.
Also re-lays-out on
document.fonts.ready— a web font arriving after firstpaint changes every width, and without this the layout stays committed to
measurements taken in the fallback face.
2. An issue seeder.
node scripts/seed-issues.mjsfiles the starter issues in one command. Safe tore-run;
--dry-runand--printincluded.Verification
Checked in a browser at 1100px: 13 events across 8 lanes, 0 overlapping
labels, 24 ticks. All 87 tests pass. Bundle 15.9 KB gzipped.
Screenshots
Not attached — the change is a layout correction rather than a visual redesign;
the axis looks the same, with tighter rows.
npm testpassesnpm run buildpassespackages/corehave a test — n/a, this ispackages/element