Update relative color parsing to latest spec#465
Conversation
…lative-color-update
…oklch colors"" This reverts commit 81cd955.
68a1bff to
3930139
Compare
|
@devongovett what would it take to merge this? Tailwind v4 css (for example) ships |
|
So, either we merge it and accept the breaking change as a "fix" since the spec itself had a breaking change, make it opt-in (not great for new projects), or wait for a major version of lightningcss. |
|
I vote for shipping it as a fix. I can't imagine there are many people relying on this behavior. |
|
On the flip side, I don't know that anybody would be bothered by a major version change that didn't actually change anything meaningful? That probably is the safest bet and, IMO, there is no real reason to wait for a major version? |
…lative-color-update # Conflicts: # src/lib.rs # src/properties/custom.rs # src/values/calc.rs # src/values/color.rs
|
I decided to just go ahead and merge this. If it breaks something, I blame the CSS spec authors. 😂 |
Closes #809
The CSS spec was updated in w3c/csswg-drafts#7876 to treat many channel values as only numbers rather than percentages or numbers for the purposes of calculations in relative colors. This is a breaking change since it no longer allows syntax like
calc(l + 10%), you need to docalc(l + 10)orcalc(l * 1.1)depending on what you want to do. In addition, the range of each channel is different, for examplelis 0-100 in lch, but 0-1 in oklch.Unfortunately, we did not ship relative color syntax under a draft flag, so if we release this change in a minor version it might be an unexpected breaking change. Haven't decided what to do here yet.