Re: [csswg-drafts] [css-color-5] Commas in color-mix()? (#6066)

The CSS Working Group just discussed `Commas in color-mix()`, and agreed to the following:

* `RESOLVED: Add back commas`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: Commas in color-mix()<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6066<br>
&lt;fantasai> leaverou: Since we have rule that ? reptition should use commas but not other things<br>
&lt;fantasai> leaverou: we removed commas from color-mix because not a list<br>
&lt;fantasai> leaverou: but it doesn't read very nicely, and not clear which color the percentage belongs to<br>
&lt;fantasai> leaverou: so thinking to add the colors back<br>
&lt;Rossen_> q<br>
&lt;fantasai> leaverou: since we can't keep going back and forth about it, UAs are implementing<br>
&lt;fantasai> leaverou: Wanted to resolve this once and for all<br>
&lt;fantasai> leaverou: I also agree it's more readable with commas<br>
&lt;TabAtkins> q+ to agree<br>
&lt;una> q+<br>
&lt;fantasai> leaverou: I think it should have a comma to separate metadata from list of colors<br>
&lt;una> to also agree (we need commas)<br>
&lt;fantasai> leaverou: clarify whether about the first color or the function as a whole<br>
&lt;fantasai> leaverou: Seem to have consensus on adding them back<br>
&lt;fantasai> leaverou: Also, do we still have 'in' for color space?<br>
&lt;fantasai> leaverou: Seems like only have color space in the beginning<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;Zakim> TabAtkins, you wanted to agree<br>
&lt;fantasai> TabAtkins: Agree with leaverou<br>
&lt;fantasai> TabAtkins: we're not attached to using commas everywhere like JS is<br>
&lt;fantasai> TabAtkins: only use it in some places<br>
&lt;fantasai> TabAtkins: It works reasonably here<br>
&lt;fantasai> TabAtkins: and helps with readability<br>
&lt;fantasai> TabAtkins: and we should also have the metadata in a single thought at the beginning, separated by comma<br>
&lt;fantasai> TabAtkins: consistent with gradients and shapes<br>
&lt;fantasai> TabAtkins: so +1 to what leaverou suggested<br>
&lt;Rossen_> ack una<br>
&lt;fantasai> una: I agree that commas are needed here<br>
&lt;fantasai> una: much like gradients<br>
&lt;miriam> +1 need commas<br>
&lt;fantasai> una: I also want to add, I don't think we need end keyword if we have this syntax<br>
&lt;leaverou> q+<br>
&lt;fantasai> una: I think we are reaching consensus in the issue, and +1 to proposal<br>
&lt;chris> s/end/in<br>
&lt;aja> fwiw, emilio landed on nightly, used commas, &amp; % applied to 2nd color, "in srgb" at start or end. willing to change<br>
&lt;fantasai> leaverou: I would argue for 'in' keyword<br>
&lt;Rossen_> ack leaverou<br>
&lt;fantasai> leaverou: it reads better, and also lets us expand the syntax later to add more options<br>
&lt;fantasai> leaverou: So, makes it more readable and makes syntax less ambiguous, so argue to keep it<br>
&lt;fantasai> Rossen_: Seems like we have consensus around adding commas, any objections?<br>
&lt;chris> great, emilio already implemented what we are about to resolve &lt;3<br>
&lt;fantasai> RESOLVED: Add back commas<br>
&lt;una> q+<br>
&lt;fantasai> Rossen_: Next one is do we want to have the 'in' keyword<br>
&lt;fantasai> una: I would like to object to it<br>
&lt;Rossen_> ack una<br>
&lt;leaverou> q+<br>
&lt;aja> chris, except for which color the percentage applies to<br>
&lt;TabAtkins> Also object, we don't use these sorts of intro keywords except absolutely necessary for disambiguation.<br>
&lt;fantasai> una: Reasoning, I don't think it's necessary and we don't have a construct of 'in' elsewhere in CSS, so introduces new concept not seen anywhere else and I don't think it adds clarity<br>
&lt;astearns> we have 'at' elsewhere<br>
&lt;fantasai> una: Don't want to add new syntax to CSS<br>
&lt;TabAtkins> Colorspace keywords are plenty clear and won't block our extensibility in the future.<br>
&lt;fantasai> Rossen_: OK, I suggest we open a separate issue for this<br>
&lt;TabAtkins> astearns, yeah, that's for disambiguation<br>
&lt;TabAtkins> because there are two positions<br>
&lt;Rossen_> ack leaverou<br>
&lt;fantasai> leaverou: Using prepositions for metadata in functions is common in gradients as well, which is where I got the inspiration. But agree with separate issue.<br>
&lt;fantasai> TabAtkins: I'm happy to argue that gradients are special<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6066#issuecomment-790193931 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 4 March 2021 00:45:48 UTC