- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jan 2021 17:31:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color?`, and agreed to the following: * `RESOLVED: All new color functions serialize to themselves` * `RESOLVED: Make the first param in the color function, the color space, required` * `RESOLVED: Have the minimum precision raised to 10 bits` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5825<br> <dael> chris: I added some comments before the call to clarify the options. two questions, what to do for lab and lch and what do for extended precesion<br> <dael> chris: Spec says if you use lab and lch lch serializes to lab. But if you do color (lab) it serielizes to color. Suggested is all three serialize to lab. I'm willing but wanted feedback to if it's an improvement<br> <dael> leaverou: On one hand have the rule values serialize to shortest form. Might be helpful for authors if number of formats returned is fewer than ones spec.<br> <TabAtkins> We shouldn't change the specified function like this - color() should remain color()<br> <dael> leaverou: I can see arguments for serializing anything that doesn't need backwards compat as color<br> <dael> astearns: TabAtkins mentioned something on IRC. I believe color emains color and it's only when serialized with a bare lch or lab<br> <dael> chris: correct<br> <chris> Tab, not a proposal<br> <dael> astearns: I can see argument for shortest that if your color happens to have a lab we could serialize to that<br> <dael> TabAtkins: Confused. First post on thread asks for that. Color with lab color space to serialize to lab function<br> <dael> TabAtkins: My assumption is lab should be used when refer to color of lab space<br> <dael> chris: I hadn't read as meaning that. I read as unclear and said spec says what to do. Then it drifted to should we harmonize<br> <dael> TabAtkins: WE shoudln't change function in a major way. They should get back out what they put in. Color function has a lot more functionality than individual color functions. Would be strange to lose that. In TypedOM it would serialize to form w/o fallbacks<br> <dael> chris: Agree. If you look at my A and B options I don't propose do away. A is continue as is. B is serialize as color(lab)<br> <dael> chris: Clearer?<br> <dael> TabAtkins: Yes<br> <dael> TabAtkins: Taking that opinion we shouldn't do B because unexpected. I think maybe not A b/c I find it weird<br> <dael> chris: When discussed previously seems to be what people want.<br> <dael> TabAtkins: That's true<br> <argyle> i like option B as well<br> <dael> plinss: I agree with TabAtkins it's strange if functions changed. If we get to world with typed om where it serliazes as the same function the author created. Will make a world of hurt if functions change, esp if inconsistent<br> <leaverou> leaverou: hsl() also serializes as rgb(), so lch serializing as lab is the same<br> <dael> astearns: argyle you mentioned you like changing in IRC?<br> <TabAtkins> Note that the TypedOM will give trivial conversions to whatever function form you want.<br> <dael> argyle: I like it. I am acknlowedging hsl serializes to rgb. It is the common space. Most common is where tried to serialize. I like in option b you can write in either syntax and get the superset. You get the higher order. It seems like it upgrades colors not downgrade or transfer.<br> <bkardell_> of the two I like B better too, I think - but it's really hard to say without actually using it and living with it for a while :-p<br> <dael> chris: I see a comment the typed om gives color conversion functions. That's not clear to me. I thought that was case but I think I see it gives a null string. Discussion on twitter it should be separate spec.<br> <dael> chris: I believe in future there will be color conversion functions, though.<br> <dael> chris: That's broader. I could type hsl and get lab. That's much broader.<br> <TabAtkins> That Twitter discussion is not reflective of the current spec or my continued intention, fwiw.<br> <dael> leaverou: Even though typed om helps b/c authors don't parse manually, they still have to handle different formats b/c closely tied. If lab serializes as color(lab) it's unclear to me what typed om class will corrispond. serialization or specified?<br> <dael> TabAtkins: typed om reifies to the class function it would serialize to. spec you get what you put in and computed it's rules for conversion<br> <dael> TabAtkins: Another reason not to change into color is class corrispondant to color is more difficult to work with than lab or lch class. If people using anything else would prefer to give easiest to work with.<br> <fremy> What TabAtkins just said makes a lot of sense to me<br> <dael> leaverou: The more different classes and author could expect they need to handle. If they don't know color thye have to handle out<br> <dael> TabAtkins: Can convert to any form they want<br> <dael> astearns: And if they return color they would still need to deal with first param with all the variations<br> <dael> chris: Hearing arguments on both sides but no clear consensus.<br> <dael> smfr: Can you summarize?<br> <astearns> options: https://github.com/w3c/csswg-drafts/issues/5825#issuecomment-763722847<br> <dael> chris: The ones in GH. Option A is serialize lab and lch with shortest form which is lab.<br> <dael> chris: Option B i slbal and lch as color(lab)<br> <TabAtkins> I was worried about that because Sam proposed it in the original post. ^_^<br> <dael> chris: TabAtkins was an option c that serializes color(labl) as lab. I only see objections to that.<br> <TabAtkins> s/was an option/was worred about an option/<br> <dael> smfr: Have to consider along with serliazation of rgba and srgb. If you look at comment from 3 days ago from Sam he suggests [reads] and lab is odd one out<br> <dael> smfr: One of the considerations is if you used color for srgb you want to round trip precision.<br> <dael> chris: Agree in general. color 3 required round to 8 bits. Currently min is 8 bits on both. Happy to increase for color which might make sense. I don't know how much existing code exists elsewhere but none for color form.<br> <dael> chris: It's always been 0 to 1 so you had precision<br> <dael> leaverou: If this is higher precision we could consider opt in to other handling<br> <TabAtkins> My preferred option: serialize lab() to lab(), lch() to lch(), and color(anything) to color(). I'd accept serializing lch() to lab() if necessary, but would prefer to avoid that.<br> <dael> smfr: One approach would be consider rgh/hsl as legacy and all newer colors serialize with color function<br> <dael> chris: I can see that as clear<br> <dael> leaverou: TabAtkins would you argue for changing how hsl serializes?<br> <dael> TabAtkins: Long past impossible at this point<br> <dael> TabAtkins: In an ideal world yes, but the compat is out of our hands<br> <dael> chris: I quite like smfr suggestion. Color rgb serialzes as itself. Therefore lab serializes as color(lab).<br> <dael> smfr: That falls out. Can see it's annoying for authors<br> <dael> chris: That's the case in both suggestions. We could change that<br> <dael> TabAtkins: Only reaon lch serializes to lab is analogy?<br> <dael> chris: Yes<br> <dael> smfr: My thought was color function is used to describe the color space and therefore lab and lch are lumpped together. Maybe not great for serialization<br> <dael> chris: Little legacy, but ongoing impl. Time to change it is now. In 6 months it's too late to change<br> <dael> TabAtkins: b/c you came in later, I'm moderatly against normalizing to color function because typed om form is a lot more complicated than individual color functions. I would prefer to give the simplier forms if they put them in.<br> <dael> smfr: Reasonable<br> <TabAtkins> Omitting the srgb keyword is stadnard "shortest form serialization" stuff, I'm fine with that.<br> <dael> chris: Since talking about sRGB. The first param is the color space and it defaults to srgb. Two ways to default it. If code is looking at this in serialized forms maybe it's cleaner if it always has an explicit color space. I can argue either way. Shortest serializable or explicit color space<br> <dael> smfr: Question, if you spec rgba with % which means >8 bit. If that serializes do you maintain precision?<br> <TabAtkins> Proposal: the sRGB functions all serialize to rgb() (partially legacy, and partially consistency). All other functions serialize to themselves.<br> <dael> chris: Currently, in color 4 they are no longer int. You can do 137.5 and it's supposed to go to highest possible with a min of 8 bits. Most impl seems ot truncate<br> <leaverou> TabAtkins: hwb() too?<br> <dael> smfr: IN WK we use color function to trigger higher precision storage.<br> <leaverou> TabAtkins: it's an sRGB function, but no legacy implications<br> <dael> chris: Lots of int precision on the web. I've read people worry about blowing up dom if it's bigger<br> <TabAtkins> leaverou: Yes, that's the "partially consistency" I mentioned. ^_^<br> <dael> astearns: TabAtkins has a proposal to have all legacy rgb serialize to rgb and all new serliaze to themselves. Sounds like people are okay with new functions serialize to themselves<br> <dael> chris: That would amount to option A.<br> <dael> astearns: Option A except lch serializes to lch<br> <TabAtkins> But I'm also fine with just "the current legacy functions serialize to rgb(), everything else to itself"<br> <dael> chris: Okay<br> <dael> leaverou: If we do srgb to itself it also makes sense to keep lab as itself. It's same thing, really<br> <dael> chris: Right<br> <dael> astearns: One person I haven't heard from in a bit is plinss. Would you be okay with this?<br> <dael> plinss: That's what I argued for. I don't believe functions should change to other functions<br> <argyle> 👍🏻<br> <dael> astearns: Prop: All new color functions serialize to themselves<br> <dael> RESOLVED: All new color functions serialize to themselves<br> <TabAtkins> color(srgb 1 0 0) should seiralize to color(1 0 0), per shortest-serialization<br> <dael> chris: Follow up on that. If I say color(srgb) it's same as color(rgb) if i just give rgb. Should they both go to the same form and if so which?<br> <dael> astearns: TabAtkins says shortest omitting defaults<br> <tantek> regrets+<br> <bkardell_> +1 lea<br> <dael> leaverou: Not sure it's good to have this form without a color space<br> <fantasai> +1 lea<br> <dael> chris: I see both arguments. Strong opinions?<br> <argyle> +1 lea<br> <dael> smfr: I would prefer srgb as explicit<br> <TabAtkins> I'd be fine with removing the optionality of the keyword<br> <dael> plinss: We're talking about the color function optionally losing srgb?<br> <dael> chris: Making it mandatory<br> <dael> plinss: When it serializes out you don't have it<br> <dael> chris: That's one option. We're talking if you want srgb you have to say so<br> <dael> leaverou: And I see agreement for that in irc<br> <florian> +1<br> <dael> plinss: Gotcha. no strong opinion<br> <dael> chris: I think it's consistent with your argument plinss<br> <dael> plinss: It's fine. If color space is optional in function I'm fine if it serializes without, but also fine with it not optional<br> <dael> leaverou: Can make optional in the future. If we start optional we cna't change<br> <dael> chris: I'm fine removing the optionality<br> <JaseW> What’s the reason Zakim pinged me?<br> <dael> astearns: Make the first param in the color funciton, the color space, required<br> <dael> RESOLVED: Make the first param in the color function, the color space, required<br> <dael> chris: I can edit this in<br> <dael> astearns: Something about precision?<br> <TabAtkins> Just clarifying - does the first resolution apply to hwb() serializing as itself?<br> <dael> chris: Yes, if you use srgb you expect higher precision. Min is 8 bits right now. I'd like to increase. P3 min is 10 bits per component. COuld make same<br> <dael> astearns: Prop: Hvae the minimum precision raised to 10 bits<br> <dael> RESOLVED: Have the minimum precision raised to 10 bits<br> <dael> chris: hwb is same as hsl where it comes out as rgb or rgba<br> <TabAtkins> I'm fine either way fwiw<br> <TabAtkins> non-sRGB functions<br> <dael> astearns: Resolution about all color functions is ammended to different way of expressing rgb?<br> <dael> chris: I see hwb as same as hsl<br> <dael> astearns: Amended resoltuion is now non-rgb color functions serialize to themselves<br> <leaverou> s/I see hwb as same as hsl/I see hwb as similar to hsl/<br> <dael> chris: Yes<br> <dael> astearns: Is that first part of issue or all covered?<br> <dael> chris: Covered that. I think I'm good<br> <dael> leaverou: If color srgb has higher precision and difference between that and srgb is maintained can the colors opt into better interpolation? Right now we have backwards compat but doing it in lch is far better. If they don't have backwards compat concerns maybe they can opt into better<br> <argyle> well said Lea!<br> <dael> astearns: leaverou can I ask you to open a separate issue? That way people can weigh in on GH<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5825#issuecomment-763811221 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 January 2021 17:31:22 UTC