Skip to content

Fix oklab/oklch lightness misparsed as percentage when given as a number - #225

Merged
FlorianRappl merged 1 commit into
AngleSharp:develfrom
scasteran-jw:feature/#224
Aug 19, 2026
Merged

Fix oklab/oklch lightness misparsed as percentage when given as a number#225
FlorianRappl merged 1 commit into
AngleSharp:develfrom
scasteran-jw:feature/#224

Conversation

@scasteran-jw

Copy link
Copy Markdown
Contributor

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

  • I have read the CONTRIBUTING document
  • My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

  • Bug fix (non-breaking change which fixes an issue, please reference the issue id)
  • New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • My change requires a change to the documentation
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed

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 range
0%–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 internally
divides by 100. Percentages worked (40.1%40.1), but numbers didn't
(0.401 stayed 0.401 → scaled down to 0.00401), producing a near-black
color instead of the intended one.

Fix

ParseLabComponent in ColorParser.cs now takes an optional numberScale
factor applied only to the unitless/number form (percentages are unaffected).
ParseOklab/ParseOklch pass numberScale: 100.0 for their L component so
0.401 is normalized to 40.1, matching 40.1%.

lab()/lch() and the a/b/c/h components of all four functions were
left untouched — their number and percentage forms already share the same
native range per spec, and no failing test indicated an issue there.

Testing

  • Added ParseOklchNumberToRgb_First/_Second and ParseOklabNumberToRgb_First/_Second,
    asserting the number form produces the same RGB output as the existing
    percentage-form tests.
  • Full test suite: 1999/1999 passing.

@CLAassistant

CLAassistant commented Aug 19, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@FlorianRappl FlorianRappl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@FlorianRappl FlorianRappl added this to the v1.0.2 milestone Aug 19, 2026
@FlorianRappl
FlorianRappl merged commit 4df8201 into AngleSharp:devel Aug 19, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants