- From: weinig via GitHub <sysbot+gh@w3.org>
- Date: Sat, 16 Jan 2021 20:24:33 +0000
- To: public-css-archive@w3.org
No need to apologize, thanks for looking into it. Not that this should play much all too much into how this plays out, but in WebKit, what we do right now is: For `rgb()`, `rgba()`, `hsl()`, `hsla()`, any named color or color using the hex notation: - we store the color internally as sRGB-8888 - we serialize as either `rgba()` or `rgb()` if alpha is 255 For `color(srgb ...)` - we store the color internally as sRGB-FFFF - we serialize as `color(srgb ...)` For `color(display-p3 ...)` - we store the color internally as DisplayP3-FFFF - we serialize as `color(display-p3 ...)` For `lab()`, `lch()` and `color(lab ...)` - we store the color internally as Lab-FFFF - we serialize as `lab(...)` I've included the internal storage here because that is what we _currently_ use to indicate to serialization what form it should use, but that is something that we can change if needed (we could, for instance store extra information about what style to serialize to, as we have some extra bits to spare in our color type). Looking at this set, the thing that pops out to me as perhaps making the most sense would be to serialize all "new" (e.g. not those grandfathered into the 1rgba()` or `rgb()` serializations) colors using the `color(... )` notation, and think of the other syntaxes as sugar in the same way that `hsla()` is sugar for `rgba()`. The change that would make in WebKit is that instead of serializing `lab()`, `lch()` and `color(lab ...)` as `lab()`, we would serialize it as `color(lab ...)`. -- GitHub Notification of comment by weinig Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5825#issuecomment-761627726 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 January 2021 20:24:35 UTC