[css-color-4] Consider removing lab(...) and lch(...) syntax and using color(lab ...) and color(lch ...) only

[weinig]

I'd like to propose unifying on the color() function syntax for new color types to simplify and unify things.

Right now, you can specify Lab colors directly via lab(...) and color(lab ...) and indirectly via lch(...). Since we have a construction for colors with fallbacks in the color(...) function already, I think unifying new color descriptions like Lab and LCH to use it would be a nice simplification while we still can. I think this would ease both user understanding (we can say all these new color types use the same syntax) and somewhat ease implementation burden (though I don't really think that should play into it, and it is tiny).

Anyway, food for thought.

[tabatkins]

I'm not a fan of this. It's a break from established tradition with color functions, it's more typing, you can't do lch() in color()'s syntax (channels are all number/percentage, not angle), and color() requires a more complex and harder-to-use TypedOM representation than the dedicated color functions.

[svgeesus]

Since this issue was opened, we have removed the fallbacks from color(), which simplifies it and makes it more like the other functional notations lab() and lch().

The points made by @tabatkins regarding brevity and also the complication of allowing a hue angle (would we also add hsl and hwb to color()?) make me tend to want to close this issue with no change.

[weinig]

I think the oddity of having two serializations of Lab (lab() and color(lab...)) is still quite odd, and adds a bunch of complexity to the implementation since we need to track which way the color was written.

Perhaps we could consider leaving lch() alone and removing lab() in favor of just color(lab ...)?

[svgeesus]

We could. Originally color() did not include lab; it was added at the suggestion of @smfr

[svgeesus]

It would be good to get the thoughts of other implementers ( @faceless2 ? ) and content creators on

1. Just have lab(), remove lab from color()
2. Just have color(lab ...), remove lab()
3. Have both lab() and color(lab ...) (the current situation)

[svgeesus]

Personally, the logical flow of section Device-independent Colors: Lab and LCH followed by Profiled, Device-dependent Colors - plus the descriptive flow of subsections in those two sections - seems clear. So in terms of specification organization, I would rather keep it that way rather than "oh and if you want to actually specify a Lab color, see the color() section".

I take the point about keeping track of which way Lab was specified, so of the three choices above my preference would be option 1. Just have lab(), remove lab from color().

[faceless2]

(@weinig, you're on the Safari team I think?)

I think it would be a shame to lose lab() - it's short. Short is good.

If I'm honest I can't see that color(lab) is going to help anyone - it's conceptually nice to have a single way of addressing all the colorspaces, but as we're missing device-cmyk, lch and so on from that syntax already so if it's just there for consistency, we've missed that target already.

Removing it for us is literally one line of code and we're still not shipping, so if it's causing more work for anyone else we're absolutely fine with dropping it.

[LeaVerou]

What if we just change the serialization so that it doesn't need to be preserved whether it was specified as lab() or color()? We obviously need to preserve it for sRGB, but not sure there's any strong rationale for preserving the difference here, except that we have a recent resolution that except legacy colors, colors are serialized as specified. We can always change that (though color(srgb) would need to be preserved regardless).

[tabatkins]

I'd much rather have a single canonical syntax than a single canonical serialization.

Since we only added color(lab) at @smfr's suggestion, and we're discussing removing it at @weinig's suggestion, I suggest we let the Apple folks work out amongst themselves which they'd prefer and let us know when they've come to an agreement. ^_^

[svgeesus]

@faceless2 wrote:

(@weinig, you're on the Safari team I think?)

Yes. Implementer of CSS Color 4 in BFO Publisher, meet implementer of CSS Color 4 in Webkit :)

[css-meeting-bot]

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()

The full IRC log of that discussion

<dael> Topic: [css-color-4] Consider removing lab(...) and lch(...) syntax and using color(lab ...) and color(lch ...) only
<chris> q+
<dael> github: https://github.com//issues/5887
<dael> leaverou_: I did not open this so not sure I should present. I could.
<dael> chris: I'm happy to present
<astearns> ack chris
<dael> chris: Basically issue is we have 2 ways to express lab
<dael> chris: Have to be kept separate in the impl. Keep track of which used. Do we need 2?
<leaverou_> q+
<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
<leaverou_> +1 to smfr's reasoning for color()
<TabAtkins> q+
<argyle> +1
<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
<dael> smfr: Someone uses tooling doing all their colors with color funt and want roundtrip with 10bit
<dael> smfr: Okay if we remove, but for completeness it makes sense to have
<astearns> ack leaverou_
<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
<florian> q+
<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.
<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
<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
<dael> leaverou_: Might even be value in normalizing coord in a 0-1 range and then color can generic spec any color supported
<astearns> ack TabAtkins
<chris> angles in [0..1] eww no
<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
<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
<astearns> ack argyle
<dael> TabAtkins: Support keeping lab and lch functions and if nec drop lab from color
<argyle> i am?
<argyle> np =)
<astearns> ack florian
<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?
<dael> chris: It is. Higher precision requirement
<dael> leaverou_: Interpolates differently as well
<dael> florian: Thank you
<dael> astearns: Seems like things have gone somewhat afield. The question of if we have lab and lch in color function or just lab?
<dael> chris: Just lab
<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)
<dael> chris: Can you explain why tracking which method used? Seralization?
<dael> smfr: Yep
<dael> leaverou_: If they were parse time aliases would have same problem?
<dael> emilio: No, but then need to decide one
<dael> astearns: And then arbitrarily changing how things spec in style sheet for impl-only reason
<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.
<dael> astearns: Sounds like a slight reason to drop lab from color. no strong opinion
<argyle> agree with what alan just said
<dael> chris: My preference too. Can see both arguments
<dael> smfr: Can live with dropping lab from color
<chris> +1
<dael> astearns: Prop: Drop lab from color()
<dael> astearns: Anyone arguing against?
<dael> astearns: Objections?
<dael> RESOLVED: Drop lab from color()
<chris> Thanks for the explanation @smfr helpful
<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
<fantasai> +1 leaverou_
<dael> leaverou_: Means in future might have color color formats spec by both color() and own function. Wouldn't that cause same problem?
<dael> astearns: it would
<chris> It would, but no clash as the custom one use dashed-ident
<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
<chris> I see
<dael> leaverou_: chris, not talking custom color spaces, talking about new predefined
<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
<dael> astearns: I don't know we have a strong precident for colors in future
<dael> leaverou_: Can have angle in color. Current grammar doesn't allow, but not reason not to
<chris> The current grammar allows hue angles to omit a unit
<dael> TabAtkins: Id on't think we can do custom colors spaces with angle so would have to special case predefined which is weird
<dael> leaverou_: It does
<faceless> +1 to "ew"
<dael> fantasai: Could predfine at 360deg
<fantasai> s/predefine at/define as 100% of
<dael> chris: Ew. Can drop unit ID right now so can say 40 for 40deg
<argyle> 1 is pretty convenient to use with display-p3 tho, i know i'm hitting max without knowing what the max number is
<dael> astearns: Is there an issue?
<dael> chris: No
<dael> astearns: Should be?
<dael> TabAtkins: No reason to yet. No color which can be spec uses an angle yet
<dael> chris: I bleive that's correct
<dael> astearns: leaverou_ should we revisit the resolution or move on?
<dael> leaverou_: okay