- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 May 2023 16:48:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-values-4][css-color] Addition of `<color>` is way underspecified.``, and agreed to the following:
* `RESOLVED: Colors don’t add; add a note asking for use cases and a warning specifying we might change in the future`
<details><summary>The full IRC log of that discussion</summary>
<emeyer> chris: The original text about adding color was from the sRGB days and it assumes consistent color spaces<br>
<emeyer> …It turns out nothing actually depends on this<br>
<emeyer> …We could say colors don’t add, or we pick something good since there’s no backwards compatibility issue<br>
<emeyer> …I propose the latter<br>
<emeyer> …so I have everything I need to add to the spec<br>
<dbaron> (you're sure smil animation doesn't depend on this?)<br>
<fserb> q+<br>
<emeyer> TabAtkins: I’m unclear when it would be useful to do an additive animation to a color, I suspect we should just go the simplest route and say colors don’t add<br>
<flackr> q+<br>
<fserb> q-<br>
<emeyer> chris: That is simple and easy, yeah<br>
<emeyer> TabAtkins: Additive transforms make more sense, but colors seem a lot more integrated and meaningful<br>
<fserb> +1 to tabatkins<br>
<Rossen_> ack flackr<br>
<emeyer> flackr: I commented on another issues that adding colors should be treated as composition of that color<br>
<TabAtkins> composition certainly makes more sense than component addition<br>
<TabAtkins> tho *which* composition is always a question<br>
<emeyer> …This to me feels like the thing you’re trying to express when adding a color to another color<br>
<chris> q+<br>
<emeyer> …I think that interpretation solves the color-space question<br>
<florian> q?<br>
<emeyer> …Because it goes to the color space of whatever you’re compositing onto<br>
<fantasai> https://www.w3.org/TR/web-animations-1/#effect-composition<br>
<Rossen_> ack fantasai<br>
<fantasai> enum CompositeOperation { "replace", "add", "accumulate" };<br>
<emeyer> fantasai: The addition of values is defined in web animations and there’s a composite operation that lets you change how you’re doing it<br>
<fantasai> https://www.w3.org/TR/web-animations-1/#the-compositeoperation-enumeration<br>
<emeyer> …That’s where this whole definition came from<br>
<emeyer> …It seems like replacement is not what’s intended<br>
<Rossen_> ack chris<br>
<emeyer> …I don’t know that defining this as replacement is what we want, long-term<br>
<TabAtkins> I think the Web Anim use of the word "composited" is unrelated to the "composition" that flackr just mentioned<br>
<emeyer> chris: What was described as compositing on top of is interpolation, which is defined a sentence earlier<br>
<emeyer> …So in one case, we point off to the interpolation definition, and the other case, we say you can’t do it<br>
<fantasai> TabAtkins, yes, but follow that link<br>
<fantasai> It's switching between replace/add/accumulate<br>
<emeyer> TabAtkins: Rob is describing compositing, not interpolating<br>
<emeyer> chris: The only difference is the color space you do the compositing in, but it’s still interpolation<br>
<fserb> q+<br>
<TabAtkins> fantasai, yes, that's still not what flackr is talking about<br>
<fantasai> no, it's not<br>
<emeyer> flackr: You do get weird interpolations with opacities involved<br>
<fantasai> I'm saying, that's what's defining that replacement and addition should be different<br>
<TabAtkins> they're different *if* you define an addition operation. if you don't, they're the same<br>
<emeyer> fserb: I think we shoudl step back and focus on the first question<br>
<fantasai> There was an assertion that the definition of addition isn't used<br>
<emeyer> …My feeling is that even if we don’t have a use case right now, we should lean toward not adding<br>
<fantasai> and it is, in WA1<br>
<emeyer> …Just in case we find reasons to do it in the future<br>
<TabAtkins> it's not used *in practice*, chris said<br>
<emeyer> chris: I tend to agree that if we don’t have a use case, we shouldn’t spec it<br>
<lea> agreed that not adding is easier to extend in the future vs some random addition algorithm<br>
<flackr> q+<br>
<emeyer> …I don’t think a lot of thought went into this bit of the spec because it didn’t get exercised<br>
<emeyer> fantasai: Are you saying there’s no use case, or that there’s no room for it in CSS?<br>
<emeyer> chris: That there’s no use case<br>
<fserb> ack fserb<br>
<fantasai> s/no room for it/no way for the definition to get used/<br>
<Rossen_> ack fserb<br>
<Rossen_> ack flackr<br>
<emeyer> flackr: I do think there are use cases, like modifying underlying color by some amount as with transforms<br>
<emeyer> …I think the risk of not doing tsomething now is that it could become a breaking change in the future<br>
<emeyer> …I think if we assume they don’t add, then the result is you get the second color, as it replaces the first<br>
<emeyer> chris: I believe that’s correct<br>
<emeyer> Rossen_: So this is really a what-if, there’s no use case<br>
<emeyer> …So what do we do?<br>
<emeyer> …We can remove it from the spec until someone comes up with a use case<br>
<emeyer> …We could leave it as is<br>
<lea> q?<br>
<emeyer> flackr: I’m very much against the current behavior<br>
<emeyer> chris: Same here<br>
<emeyer> lea: Agreed<br>
<TabAtkins> it wasn't underspecified at the time, fwiw - back when it was written colors were specified as sRGB<br>
<emeyer> Rossen_: What if we bring all of it back to the whiteboard, and maybe find some use cases in the meantime?<br>
<TabAtkins> clearlly not something we want to do now<br>
<emeyer> …How does that sound?<br>
<fserb> I'm good with this too<br>
<emeyer> chris: So we’re effectively resolved they don’t add now, and can change it later<br>
<emeyer> TabAtkins: Plus add a note saying we’d like use cases<br>
<emeyer> fantasai: And that we might change it in the future<br>
<emeyer> Rossen_: Objections to the note and warning?<br>
<emeyer> plinss: I’m a little concerned about not doing things when we don’t have use cases<br>
<fserb> q+<br>
<emeyer> …What’s the justification for not doing it?<br>
<emeyer> …Authors might come up with cool stuff once a possibility is out there<br>
<emeyer> TabAtkins: There’s a lot of ways of defining addition, and without use cases, it’s an arbitrary choice<br>
<flackr> add rgb(0, 0, 0, 0.1) /* darken */<br>
<emeyer> …If we decide that for now we don’t add at all, authors can still get what they want by doing their own blending<br>
<emeyer> …We don’t have an obvious behavior to bless here<br>
<fantasai> +1<br>
<emeyer> fserb: There are a lot of axes you can change colors on, none of which are “add"<br>
<emeyer> Rossen_: I didn’t hear objections, and peter’s concern seems addressed<br>
<TabAtkins> flackr: reasonable to argue for the "just composite it" in the issue, if you do think we should do that<br>
<emeyer> RESOLVED: Colors don’t add; add a note asking for use cases and a warning specifying we might change in the future<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8576#issuecomment-1570575637 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 May 2023 16:48:30 UTC