Re: [csswg-drafts] [css-images] Clarify how gradients should be serialized in presence of the double-position color syntax

The Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/2714`, and agreed to the following:

* `RESOLVED: always expand gradient syntax in serialization`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: https://github.com/w3c/csswg-drafts/issues/2714<br>
&lt;fantasai> We should add an issue note in the draft tho<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2714<br>
&lt;dael> leaverou: A few weeks ago we cleared the 2 position color stop for shipping. Right now chrome serializes any gradient with 2 colors stops with same color Chrome u ses this syntax. Worried will b eak code.<br>
&lt;dael> leaverou: Options either gradient read back as it's specified or canonicalize gradients. If 2 color stops have same color they're compressed. Or never cannonicalize and always use the expanded syntax<br>
&lt;dael> leaverou: No strong opinion. Worried about cannonicalizing existing not spec this way. It could break parsing code. I w ould vote for another. Prob return expanded syntax in all cases. No strong opinion<br>
&lt;AmeliaBR> I'd also lean towards serializing with the older/explicit syntax, instead of the newer one. The new syntax is just sugar for declarations.<br>
&lt;dael> dbaron: I think 2 principles on how to define serialization. 1 is that you want to try and serialize to shorter form. THat's weaker in this case. Other is a syntax that's evolved o ver time you want to serialize to older.<br>
&lt;dael> dbaron: I think the older formprinciple should win over shorter. That still leaves remember how it was spec or always expand syntax. No strong opinion between those<br>
&lt;dael> TabAtkins: How long ago did we ship always collapse?<br>
&lt;dael> emilio: Hasn't yet.<br>
&lt;dael> leaverou: Intent to ship was a few days ago. It's Chrome 69.<br>
&lt;dael> emilio: It needs the three [missed] to ship. Needs to be resolved  on this.<br>
&lt;chris> s/[missed]/LGTM's<br>
&lt;leaverou> Correction: That's conic-gradients that will ship in 69. The 2 position syntax may ship later.<br>
&lt;dael> TabAtkins: I was hoping we had shipped with no compat. Then I vote always exapnded because keeping track of syntax is an extra bit on every stop that's not otherwise needed<br>
&lt;dael> frremy: Always expand seems better<br>
&lt;dael> leaverou: Agree<br>
&lt;dael> emilio: Seems good to me. Forget everything at parse time.<br>
&lt;dael> TabAtkins: I assume that currently we're forgetting at parse time and then going back and we can delete that bit and make it simplier<br>
&lt;dael> astearns: Objections to always expand gradient syntax?<br>
&lt;dael> RESOLVED: always expand gradient syntax in serialization<br>
</details>


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

Received on Wednesday, 30 May 2018 16:35:58 UTC