Fix oklab/oklch lightness misparsed as percentage when given as a number - #225
Merged
Merged
Conversation
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.
Types of Changes
Prerequisites
Please make sure you can check the following two boxes:
Contribution Type
What types of changes does your code introduce? Put an
xin all the boxes that apply:Description
Summary
oklab()/oklch()accept the L (lightness) component as either a<percentage>or a plain
<number>. Per the CSS Color 4 spec, the percentage reference range0%–100% maps to a number range of 0–1 (e.g.
40.1%≡0.401).The parser treated both forms identically, passing the raw parsed value straight
into
CssColorValue.FromOklab, which expects L in[0,100]and internallydivides by 100. Percentages worked (
40.1%→40.1), but numbers didn't(
0.401stayed0.401→ scaled down to0.00401), producing a near-blackcolor instead of the intended one.
Fix
ParseLabComponentinColorParser.csnow takes an optionalnumberScalefactor applied only to the unitless/number form (percentages are unaffected).
ParseOklab/ParseOklchpassnumberScale: 100.0for their L component so0.401is normalized to40.1, matching40.1%.lab()/lch()and thea/b/c/hcomponents of all four functions wereleft untouched — their number and percentage forms already share the same
native range per spec, and no failing test indicated an issue there.
Testing
ParseOklchNumberToRgb_First/_SecondandParseOklabNumberToRgb_First/_Second,asserting the number form produces the same RGB output as the existing
percentage-form tests.