Repository navigation
Apply built-in tone colours to data-driven and partial tones - #35
Merged
Merged
Conversation
The layout chose tone colours at compile time, when a data tone is
still the literal {{tone}}, and the render-time style step only used
the caller's style.tones, so data tones rendered grey. The style step
now layers style.tones over the built-in palette.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
2 participants
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.
Why
There is no ticket: this was caught while writing the newcomer docs, whose README section on tones says a tone set from data works "with only data". We caught this issue so we patched it like the rest.
What
A
<panel>or<alert>whosetonecomes from data now gets the built-in colours for that tone without astyleobject, and astyle.tonesentry that sets only some colours keeps the built-in values for the rest. Ships in 4.0.1.Changes
style.tonesentries fill in from it. The layout picks tone colours at compile time from the attribute's literal text, which fortone="{{tone}}"is an unknown name, so it wrote the neutral grey; the render-time style step recoloured only from the caller'sstyle.tones. The five built-in tones now live in one exported table insrc/layout.ts, andsrc/style.tslayers the caller's entry over the built-in tone field by field. Literal tones and fullstyle.tonesentries render byte-identical to before; an unknown tone stays grey. We caught this issue so we patched it like the rest; these are minor fixes, fully covered and encapsulated.Testing
test/layout.test.ts: the data-only tone test now asserts the info and success backgrounds, and a new test covers a partial override. Both failed before the fix and pass after.style.tonesentry, produce byte-identical HTML.npm audit --audit-level=high --omit=dev,npm test(7 files, 290 tests),npm run examplesandnpm run test:visual(5 of 5 snapshots unchanged) pass on Node 24. Node 20 and 22 run in CI.Risk and rollout
Ships in 4.0.1, which is on master but not yet published: tag
v4.0.1once this merges. Visible change: templates that set a tone from data, or pass a partialstyle.tonesentry, now get the tone's colours instead of grey.🤖 Generated with Claude Code