- From: Aaron Krajeski via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 May 2023 19:47:59 +0000
- To: public-css-archive@w3.org
> For `lab(calc(NaN) 0 0)` or `lab(calc(0 / 0) 0 0)`: > > * computed value `lab(0 0 0)` > * serializes as `lab(calc(NaN) 0 0)` > > Would that be correct? @tabatkins Even if this is correct, per spec, why do we _want_ this behavior? Does it have significant use-cases? Do other CSS properties perform this way? The reason I ask is because this would invalidate a couple major assumptions that chromium's color parser makes. Namely that the result of parsing a color function will either be failure or a `Color`, i.e. something that can be encoded with a colorspace and 4 values, which are numbers or "None." Tests verifying this are part of interop 2023 and all UAs are currently failing: https://wpt.fyi/results/css/css-color/parsing/color-valid-lab.html To pass these tests will involve restructuring things quite a bit and creating a sort of "unresolved color" type so that the color can be serialized differently at parse time than at computed time. Obviously, none of this is impossible, but I simply wanted to highlight that it is a non-trivial amount of work to support. If it's a minor use-case and other UAs are uninterested in supporting it, than I'd propose changing the spec such that: For `lab(calc(NaN) 0 0)` or `lab(calc(0 / 0) 0 0)`: * computed value `lab(0 0 0)` * serializes as `lab(0 0 0)` And for `lab(0 calc(infinity) 0)`: * computed value `lab(0 Infinity 0)` * serializes as `lab(0 Infinity 0)` So, importantly, dropping the "calc" so that the channels are all numbers. Why is it important that they roundtrip in this context? -- GitHub Notification of comment by mysteryDate Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8629#issuecomment-1564853413 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 26 May 2023 19:48:01 UTC