Repository navigation
feat(driver,react): keep the previous hue when an achromatic color is entered - #229
Merged
Merged
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This was referenced Oct 7, 2026
pbroom
force-pushed
the
feat/preserve-hue-on-achromatic-input
branch
from
October 8, 2026 02:44
2142348 to
65f7643
Compare
pbroom
force-pushed
the
refactor/core-chroma-contrast-solver
branch
from
October 8, 2026 02:44
23b69a0 to
319683f
Compare
This was referenced Oct 8, 2026
This was referenced Oct 9, 2026
Owner
Author
pbroom
changed the base branch from
refactor/core-chroma-contrast-solver
to
graphite-base/229
October 10, 2026 19:45
… entered Grays, black and white entered through non-OKLCH paths (hex/rgb/hsl strings, setFromRgb/Hsl/Hsv, RGB/HSL ColorInput edits, ColorStringInput) used to store the converted hue 0, so raising chroma afterwards jumped to red. The state layer now keeps the latest requested hue unless the input states an OKLCH hue (an oklch() string with a hue other than none, or an OKLCH object). Core parse() and conversions are unchanged. Adds driver helpers resolveIncomingRequested and hasExplicitOklchHue, and an explicitHue option on setColorRequested, setMultiColorRequested and SetRequestedOptions. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…om a gray An HSL ColorInput edit of a gray started from toHsl(gray), whose hue is the canonical 0, so raising saturation again produced red even though the requested OKLCH hue had been kept. For an achromatic color with a stored hue, HSL reads and edits now go through that hue: - the HSL hue field shows the HSL hue of the stored OKLCH hue (measured on a 1%-saturated color at the same lightness) instead of 0; - a saturation edit bisects for the HSL hue at which the new saturation and lightness have the stored OKLCH hue, so the result lands on it to within 0.01 degrees; - an HSL hue edit keeps the color gray and stores the OKLCH hue of the typed HSL hue (React ColorInput passes it as an explicit hue); - lightness and alpha edits, black and white keep the stored hue. The colorFromColorInputChannelValue JSDoc now states these guarantees. Co-Authored-By: Claude Opus 5.5 <[email protected]>
pbroom
force-pushed
the
feat/preserve-hue-on-achromatic-input
branch
from
October 10, 2026 19:48
3d7b3aa to
67081ab
Compare
This branch was successfully deployed
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.
Grays, black and white entered through non-OKLCH paths (hex/rgb/hsl
strings, setFromRgb/Hsl/Hsv, RGB/HSL ColorInput edits, ColorStringInput)
used to store the converted hue 0, so raising chroma afterwards jumped to
red. The state layer now keeps the latest requested hue unless the input
states an OKLCH hue (an oklch() string with a hue other than none, or an
OKLCH object). Core parse() and conversions are unchanged.
Adds driver helpers resolveIncomingRequested and hasExplicitOklchHue, and
an explicitHue option on setColorRequested, setMultiColorRequested and
SetRequestedOptions.
Behavior
setFromRgb/setFromHsl/setFromHsv, or a ColorInput RGB/HSL edit, the state keeps the previous requested hue instead of resetting to 0.oklch(L 0 H)string, or an OKLCH object passed tosetRequested, keeps its own hue.oklch(... none)carries the previous hue.parse()and the conversions are unchanged and deterministic.resolveIncomingRequestedandhasExplicitOklchHue.setColorRequested/setMultiColorRequestedtake{ explicitHue }, which defaults totrue.Validation of the latest correction: lint, full build including DTS, test (core 888, driver 142, React 215), format:check and agents:check:strict pass locally. The control-kit dependency was built from the pinned source after installation with scripts disabled; hosted CI remains a separate check.
Multiline
oklch()input now preserves an explicit hue consistently with the core parser. Regression coverage includes LF/CR/CRLF/tab/form-feed, zero and angle-unit hues,none, and alpha. The three line-break cases fail before the correction and pass after it.Part of the color-kit assessment stack (#204 → #229).
🤖 Generated with Claude Code