W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2018

Re: [csswg-drafts] [css-images] image-rendering should support SVG 1.1 values

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Nov 2018 00:22:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-436826546-1541636405-sysbot+gh@w3.org>
The CSS Working Group just discussed `image-rendering should support SVG 1.1 values`, and agreed to the following:

* `RESOLVED: optimizeQuality behaves the same as smooth`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: image-rendering should support SVG 1.1 values<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3283<br>
&lt;dael> Rossen_: Who can represent this?<br>
&lt;dael> ericwilligers: I'm here<br>
&lt;dael> ericwilligers: This was my mistake. I missed that it says optimize was deprecated. Coming out of that we fix optimize quality shoudl go to smooth rather than auto. Right now we're throwing away information<br>
&lt;dael> Rossen_: Is the value set auto | smooth ?<br>
&lt;dael> ericwilligers: SVG optimize-quality will become smooth instead of auto<br>
&lt;TabAtkins> auto | smooth | pixelated | &lt;other-thing-i-forget-not-relevant><br>
&lt;TabAtkins> I'm happy to do "smooth"<br>
&lt;TabAtkins> crisp-edges<br>
&lt;dael> ericwilligers: I wanted other thoughts. Current css images says optimize-quality is meaningless<br>
&lt;TabAtkins> that's the value i forgot<br>
&lt;dael> Rossen_: Any others on the call that know or care about this?<br>
&lt;dael> dbaron: What is the proposed [missed]<br>
&lt;TabAtkins> "auto" === "smooth" in practice<br>
&lt;dael> dbaron: ...proposed change?<br>
&lt;dael> Rossen_: ericwilligers can you summarize?<br>
&lt;dael> ericwilligers: I'll type it<br>
&lt;ericwilligers> This property previously accepted the values optimizeSpeed and optimizeQuality. Was These are now deprecated; a user agent must accept them as valid values but must treat them as having the same behavior as pixelated and auto respectively, and authors must not use them. Now These are now deprecated; a user agent must accept them as valid values but must treat them as having the same behavior as pixelated and smooth respectively, and authors mu[CUT]<br>
&lt;ericwilligers> optimizeQuality will now map to smooth instead of auto.<br>
&lt;Rossen_> property is image-rendering<br>
&lt;dael> ericwilligers: What we're saying is that optimizespeed and optimizeQuality are changing<br>
&lt;dael> Rossen_: Auto otherwise was sometimes pixelated?<br>
&lt;TabAtkins> auto is "whatever you want", but in practice it's "smooth"<br>
&lt;dael> ericwilligers: Auto was default. Previously images spec said optimizeQuality was eq. to not setting it at all<br>
&lt;dael> dbaron: Seems reasonable. Unless there's an incompatibility I'm not thinking about<br>
&lt;dael> Rossen_: Other opinions?<br>
&lt;TabAtkins> optimizeQualtiy being equal to "auto" is because, at the time I wrote those mappings, we just had auto and pixelated<br>
&lt;TabAtkins> I'd map it to "smooth" today<br>
&lt;dael> ericwilligers: No impl ship smooth. They all ship optimizeQuality. So we should say people can ship smooth<br>
&lt;dael> ericwilligers: Smooth should be cleared for shipping<br>
&lt;dael> Rossen_: Well shipping is a UA business decision. But we can say value smooth is initial value for<br>
&lt;dael> ericwilligers: Initial value is auto<br>
&lt;dael> Rossen_: Auto remains as initial.<br>
&lt;dael> Rossen_: optimizeQuality becomes smooth<br>
&lt;dael> Rossen_: Prop: optimizeQuality is replaced by smooth<br>
&lt;dael> ericwilligers: [missed]<br>
&lt;ericwilligers> optimizeQuality behaves the same as smooth, instead of behaving the same as auto.<br>
&lt;dael> florian: parallel we do have a thing to clear for shipping. In some cases pre-CR we say a feature is safe to ship. Browsers can still decide after that<br>
&lt;ericwilligers> (Just like the existing spec text that optimizeSpeed behaves the same as pixelated)<br>
&lt;dbaron> yeah, +1 to Florian, I was going to raise the same thing once we got the resolutions down<br>
&lt;dael> Rossen_: For sure. but this is a technical decision for a particular property<br>
&lt;TabAtkins> "clear for shipping" means that we're approving it for shipping despite the spec not being CR. It has nothing to do with impls deciding to ship or not<br>
&lt;dael> rossen: obj to optimizeQuality behaves the same as smooth ?<br>
&lt;dael> RESOLVED: optimizeQuality behaves the same as smooth<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3283#issuecomment-436826546 using your GitHub account
Received on Thursday, 8 November 2018 00:22:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:59 UTC