Make the Rendering tab's style cards say what to fix - #4861
Merged
Conversation
The Style recalculation and Style invalidations cards presented a wall of
counts and milliseconds without answering the two questions a developer
actually has: do I need to do anything here, and where should I spend my
time. Reading them well took Chrome-internals knowl
), layout: split(styleInvalidations.layout
{ title: 'Building the page', hethe document and its layout — expected work f
or the initial render (scripts inserting content later land here too). Shown for scale, not as a problem.', quiet
: true, recalc: split(styleInvalidations.rt: split(styleInvalidations.layoutReasons ||
[], true) }
{ title: 'Building the page', help: 'Nodes being added to the document and its layout: expected work fo
r the initial render (scripts inserting content later land here too). Shown for scale, not as a problem.', quiet:
true, recalc: split(styleInvalidations.recalcReasons, true), layout: split(styleInvalidations.layoutReasons || [
], true) }
)
}
//- Chrome's raw invalidation reason strings are internal jargon.
Now verify no user-facing em dashes remain, render spacing, and lint:
Ran 1 shell command
No user-facing em dashes remain, and the fixed lines render with correct spacing. Running lint:
Ran 1 shell command
Fixed. All 14 user-facing em dashes in the Renderinnts and code left untouched), replaced with periods, colons, commas, or parentheses per the rule. Lint clean.
The line you quoted now reads:
▎ The wasted-work list below (selectors tried thousands of times that never match) is the place to start.
The others fixed in the same file: the TTFB verdictdual/late-request/LCP-image lines, the "Wastedselector work" and CPU-throttle lines, the "Counts, not milliseconds" intro, and the six invalidation-group titles/help strings. My own additions from this branch were already clean.
Two notes:
- These were all pre-existing copy from main, so they're now part of this branch's diff (which is fine, but the diff for actionable-style-cards now also carries these copy fixes).
- The rest of the report (other tabs/templates) still has em dashes in user-facing copy. I kept this scoped to the Rendering
template you're reviewing. If you want, I can do a s the whole templates/ tree for user-facing emdashes in one pass — cleaner to keep that apart from the feature work. Want that?
✻ Cogitated for 4m 25s
❯ commit message
All three pieces are now on actionable-style-cards (the two verdicts, the reason translation, and the em-dash cleanup). One commit message covering them:
--- commit message ---
Make the Rendering tab's style cards say what to fix
The Style recalculation and Style invalidations cards presented a wall of
counts and milliseconds without answering the two q
actually has: do I need to do anything here, and where should I spend my
time. Reading them well took Chrome-internals knowl
have.
Each card now opens with a verdict that reads the data and points somewhere
concrete. Style recalculation grades whether it delayed the paint, then says
which of two shapes it is (one big restyle of a large container versus many
small ones that signal layout thrashing) because th
Style invalidations names the single biggest thing that keeps changing and
hands off to the script list, using the after-first
trace carried paint timestamps.
The Invalidation reasons table used to print Chrome's raw reason strings
(Affected by :has(), Inline CSS style declaration w
Those are now translated to plain language, with a one-line fix attached to
the four reasons a developer can act on. Reasons we
translate, and any future Chrome reason, fall through to the raw string with
it kept on hover, so nothing is ever mislabelled.
While in the file, the pre-existing em dashes in th
replaced with plain punctuation, matching the project's report-copy style.
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
soulgalore
force-pushed
the
actionable-style-cards
branch
from
July 20, 2026 08:22
6dca759 to
e424ebe
Compare
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 Style recalculation and Style invalidations cards presented a wall of
counts and milliseconds without answering the two questions a developer
actually has: do I need to do anything here, and where should I spend my
time. Reading them well took Chrome-internals knowledge most people don't
have.
Each card now opens with a verdict that reads the data and points somewhere
concrete. Style recalculation grades whether it delayed the paint, then says
which of two shapes it is (one big restyle of a large container versus many
small ones that signal layout thrashing) because those need different fixes.
Style invalidations names the single biggest thing that keeps changing and
hands off to the script list, using the after-first-paint split when the
trace carried paint timestamps.
The Invalidation reasons table used to print Chrome's raw reason strings
(Affected by :has(), Inline CSS style declaration was mutated, and so on).
Those are now translated to plain language, with a one-line fix attached to
the four reasons a developer can act on. Reasons we can't confidently
translate, and any future Chrome reason, fall through to the raw string with
it kept on hover, so nothing is ever mislabelled.
While in the file, the pre-existing em dashes in the user-facing copy were
replaced with plain punctuation, matching the proje
Co-Authored-By: Claude Opus 4.8 (1M context) norepl