W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css-color] Serializing color() values

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Apr 2017 03:19:34 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-296037309-1492744773-sysbot+gh@w3.org>
The CSS Working Group just discussed `Serializing color() values`, and agreed to the following resolutions:

* `RESOLVED: color() always serializes as color().`

<details><summary>The full IRC log of that discussion</summary>

```
<dino> Topic: Serializing color() values
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/480
<TabAtkins> dino: If you did "color(srgb 1 0 0)", should it serialize as that, or as "rgb(255 0 0)"?
<TabAtkins> dino: Two problems.
<TabAtkins> dino: We lose a lot of precision sending it out to rgb() - only 8 bits of precision, vs doubles.
<TabAtkins> dino: That's impacted us in real impls - the touch bar in new macs, when in editting mode you can pick a color, and those colors are in a wider color space, then if we convert to srgb you lose precision; if we send that information back up, it's not what the author said.
<TabAtkins> ChrisL_: In general I've moved Color 4 to 0-1, because it's inherently bit-depth neutral, and we're seeing devices with 10 or 12 bits per channel now.
<TabAtkins> dino: So should a color(srgb) be output as rgb()?
<TabAtkins> ChrisL_: If anything, output it as %, that's higher precision.
<TabAtkins> TabAtkins: Or just keep it color().
<TabAtkins> dino: That's what I do now. It's higher precisions.
<TabAtkins> TabAtkins: Does anyone suggest simplifying to rgb()?
<TabAtkins> dino: No, it's just not strictly defined.
<TabAtkins> dino: And now that we have the new rgb() syntax, should we serialize to that? That would probably break things.
<TabAtkins> TabAtkins: Yeah, I think we need to output in the old rgb().
<TabAtkins> dbaron: Back to color(), we could output to % and keep it higher-depth.
<TabAtkins> dino: Yeah, but it would probably break content.
<TabAtkins> dino: No content expects %s in the serialized form right now.
<TabAtkins> dino: So maybe we can suggest that rgb() is always 8-bit?
<TabAtkins> ChrisL_: Absolutely not - rec2020 is only defined over 10 and 12 bit. It woudl be a syntax violation.
<TabAtkins> dbaron: I think he was suggesting that the rgb() syntax, specifically, is 8-bit.
<TabAtkins> ChrisL_: Okay, that's fine. That then means that rgb() *must* be stuck in sRGB - it can't become rec2020.
<TabAtkins> dino: No, I really just meant that when we serialize rgb(), we round it to 8-bit.
<TabAtkins> ChrisL_: So if a user inputs with rgb(%), then serializes, what do you get?
<TabAtkins> TabAtkins: integers between 0 and 255
<TabAtkins> dino: So I think we cna resolve that color() serializes as color().
<TabAtkins> RESOLVED: color() always serializes as color().
<TabAtkins> TabAtkins: Make sure to specify whether trailing 0 args are omitted or not in serialization.
<TabAtkins> dino: I think I always output all the args. I leave off alpha if it's 1.
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/480#issuecomment-296037309 using your GitHub account
Received on Friday, 21 April 2017 03:19:41 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:11 UTC