- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 May 2021 16:42:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-4] Consider removing lab(...) and lch(...) syntax and using color(lab ...) and color(lch ...) only`, and agreed to the following: * `RESOLVED: Drop lab from color()` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-4] Consider removing lab(...) and lch(...) syntax and using color(lab ...) and color(lch ...) only<br> <chris> q+<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5887<br> <dael> leaverou_: I did not open this so not sure I should present. I could.<br> <dael> chris: I'm happy to present<br> <astearns> ack chris<br> <dael> chris: Basically issue is we have 2 ways to express lab<br> <dael> chris: Have to be kept separate in the impl. Keep track of which used. Do we need 2?<br> <leaverou_> q+<br> <dael> chris: Can delete either. People like lab b/c brief. Only added lab to color b/c sure why not when smfr asked. Since Apple is now asking to remove easiest to remove<br> <leaverou_> +1 to smfr's reasoning for color()<br> <TabAtkins> q+<br> <argyle> +1<br> <dael> smfr: Talked to Sam. Didn't come to agreement. Don't htink we're arbiters of CSS. Rational to add it is wanted color function to be superset or union of all ways to desc colors. Where there is a color function with a color space where that space could be used in first arg<br> <dael> smfr: Someone uses tooling doing all their colors with color funt and want roundtrip with 10bit<br> <dael> smfr: Okay if we remove, but for completeness it makes sense to have<br> <astearns> ack leaverou_<br> <dael> chris: Understand argument. Would be nice. As someone pointed out we missed with devicecmyk and lch. That was different a while ago but if we wanted to do this need to add lch into the color function so you would need to say this param is a hue. Doable but complex<br> <florian> q+<br> <dael> leaverou_: Opposed to dropping. nice readable syntax. could instead drop distinction and allow browsers to store color lab and lab function as the same thing.<br> <dael> leaverou_: Usefult o keep distinction for srgb colors. But spec by color isn't legacy and for lab it's the same colors. If it's complex for impl no reason to stor ehte syntax<br> <dael> leaverou_: Agree with smfr there's value in color desc all colors. Allows lib to serialize whatever color w/o special case. Nice to have, not a huge need. Nice if possible. Good to add lch and every other color we support<br> <dael> leaverou_: Might even be value in normalizing coord in a 0-1 range and then color can generic spec any color supported<br> <astearns> ack TabAtkins<br> <chris> angles in [0..1] eww no<br> <dael> TabAtkins: on the idea of unifying everything into color with lch and hsl, color only ccepts numbers and not angles. I'm not familar with math, but I don't htink color space ever has angle would would be special casing angle to the pre-defined ones. Feels odd to dup the work to color. Poss, but awk<br> <dael> TabAtkins: on leaverou_ side I would rather a single way to represent rather then 2 ways to rep with 1 serialization. I could be okay, but don't like alaising to a different value then spec and since we don't have legacy need we shouldn't invent one<br> <astearns> ack argyle<br> <dael> TabAtkins: Support keeping lab and lch functions and if nec drop lab from color<br> <argyle> i am?<br> <argyle> np =)<br> <astearns> ack florian<br> <dael> florian: Wondering, if we drop the keywords for simplification we're left with one double? Or is color with srgb keyword is that different behavior?<br> <dael> chris: It is. Higher precision requirement<br> <dael> leaverou_: Interpolates differently as well<br> <dael> florian: Thank you<br> <dael> astearns: Seems like things have gone somewhat afield. The question of if we have lab and lch in color function or just lab?<br> <dael> chris: Just lab<br> <dael> smfr: To defend Sam's point he would prefer not to have color(labl) and lab() so prefer to drop one. My preference is weak so willing to drop color(lab)<br> <dael> chris: Can you explain why tracking which method used? Seralization?<br> <dael> smfr: Yep<br> <dael> leaverou_: If they were parse time aliases would have same problem?<br> <dael> emilio: No, but then need to decide one<br> <dael> astearns: And then arbitrarily changing how things spec in style sheet for impl-only reason<br> <dael> astearns: My uninformed opinion, I kind of agree with smfr that it would be nice to have color spec any colora t all, but sounds like problems with colors that use angle. Unclear if we could get to a superset colorf unction.<br> <dael> astearns: Sounds like a slight reason to drop lab from color. no strong opinion<br> <argyle> agree with what alan just said<br> <dael> chris: My preference too. Can see both arguments<br> <dael> smfr: Can live with dropping lab from color<br> <chris> +1<br> <dael> astearns: Prop: Drop lab from color()<br> <dael> astearns: Anyone arguing against?<br> <dael> astearns: Objections?<br> <dael> RESOLVED: Drop lab from color()<br> <chris> Thanks for the explanation @smfr helpful<br> <dael> leaverou_: Question, I always assumed if we want to add new color spaces we first add in color function and if we see huge usage we might add as separate color functions<br> <fantasai> +1 leaverou_<br> <dael> leaverou_: Means in future might have color color formats spec by both color() and own function. Wouldn't that cause same problem?<br> <dael> astearns: it would<br> <chris> It would, but no clash as the custom one use dashed-ident<br> <dael> astearns: but I think argument there is this is for authors. Huge usage is worth extra effort on impl side. Maybe we wouldn't get to that decision unless usage is off the charts<br> <chris> I see<br> <dael> leaverou_: chris, not talking custom color spaces, talking about new predefined<br> <dael> astearns: I can see if at some point we figure out how to put angle spec colors into color funct we can revist color function being a strict superset and re-add lab<br> <dael> astearns: I don't know we have a strong precident for colors in future<br> <dael> leaverou_: Can have angle in color. Current grammar doesn't allow, but not reason not to<br> <chris> The current grammar allows hue angles to omit a unit<br> <dael> TabAtkins: Id on't think we can do custom colors spaces with angle so would have to special case predefined which is weird<br> <dael> leaverou_: It does<br> <faceless> +1 to "ew"<br> <dael> fantasai: Could predfine at 360deg<br> <fantasai> s/predefine at/define as 100% of<br> <dael> chris: Ew. Can drop unit ID right now so can say 40 for 40deg<br> <argyle> 1 is pretty convenient to use with display-p3 tho, i know i'm hitting max without knowing what the max number is<br> <dael> astearns: Is there an issue?<br> <dael> chris: No<br> <dael> astearns: Should be?<br> <dael> TabAtkins: No reason to yet. No color which can be spec uses an angle yet<br> <dael> chris: I bleive that's correct<br> <dael> astearns: leaverou_ should we revisit the resolution or move on?<br> <dael> leaverou_: okay<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5887#issuecomment-839930964 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 May 2021 16:42:38 UTC