[css-images] image-rendering should support SVG 1.1 values

[ewilligers]

SVG 1.1's image-rendering allows
auto | optimizeSpeed | optimizeQuality

CSS Images currently allows
auto | smooth | high-quality | crisp-edges | pixelated

Safari 11.1 supports
auto | crisp-edges | pixelated | optimizeSpeed | optimizeQuality

Blink supports
auto | pixelated | -webkit-optimize-contrast
-webkit-optimize-contrast is a non-standard naming for crisp-edges
There is also non-working code for optimizeSpeed | optimizeQuality

Firefox supports
auto | crisp-edges | optimizespeed | optimizequality

Edge does not support the property (test page).

These results suggest:

• high-quality should be renamed to optimizeQuality
• optimizeSpeed should be added
• Implementations should be asked if they intend to support smooth

[ewilligers]

I missed

This property previously accepted the values optimizeSpeed and optimizeQuality. 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.

Why doesn't optimizeQuality map to high-quality? usage is 0.3%

[tabatkins]

high-quality implies more than the old optimizequality did; it's something that should be used sparingly on a page (like will-change, it implies expensive things on the part of the UA). auto is the correct behavior for optimizequality.

Also, at the time I wrote that paragraph high-quality didn't exist. But mainly the first thing. ^_^

[ewilligers]

auto is the correct behavior for optimizequality.

Why not smooth?

optimizeQuality
Indicates that the user agent shall emphasize quality over rendering speed. The user agent shall employ a resampling algorithm at least as good as bilinear resampling.

smooth
The image should be scaled with an algorithm that maximizes the appearance of the image. In particular, scaling algorithms that "smooth" colors are acceptable, such as bilinear interpolation. This is intended for images such as photos.

[tabatkins]

Ah, now that's purely because we didn't have smooth at the time (auto served that purpose). I'd be fine with changing that.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: image-rendering should support SVG 1.1 values
<dael> github: https://github.com//issues/3283
<dael> Rossen_: Who can represent this?
<dael> ericwilligers: I'm here
<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
<dael> Rossen_: Is the value set auto | smooth ?
<dael> ericwilligers: SVG optimize-quality will become smooth instead of auto
<TabAtkins> auto | smooth | pixelated | <other-thing-i-forget-not-relevant>
<TabAtkins> I'm happy to do "smooth"
<TabAtkins> crisp-edges
<dael> ericwilligers: I wanted other thoughts. Current css images says optimize-quality is meaningless
<TabAtkins> that's the value i forgot
<dael> Rossen_: Any others on the call that know or care about this?
<dael> dbaron: What is the proposed [missed]
<TabAtkins> "auto" === "smooth" in practice
<dael> dbaron: ...proposed change?
<dael> Rossen_: ericwilligers can you summarize?
<dael> ericwilligers: I'll type it
<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]
<ericwilligers> optimizeQuality will now map to smooth instead of auto.
<Rossen_> property is image-rendering
<dael> ericwilligers: What we're saying is that optimizespeed and optimizeQuality are changing
<dael> Rossen_: Auto otherwise was sometimes pixelated?
<TabAtkins> auto is "whatever you want", but in practice it's "smooth"
<dael> ericwilligers: Auto was default. Previously images spec said optimizeQuality was eq. to not setting it at all
<dael> dbaron: Seems reasonable. Unless there's an incompatibility I'm not thinking about
<dael> Rossen_: Other opinions?
<TabAtkins> optimizeQualtiy being equal to "auto" is because, at the time I wrote those mappings, we just had auto and pixelated
<TabAtkins> I'd map it to "smooth" today
<dael> ericwilligers: No impl ship smooth. They all ship optimizeQuality. So we should say people can ship smooth
<dael> ericwilligers: Smooth should be cleared for shipping
<dael> Rossen_: Well shipping is a UA business decision. But we can say value smooth is initial value for
<dael> ericwilligers: Initial value is auto
<dael> Rossen_: Auto remains as initial.
<dael> Rossen_: optimizeQuality becomes smooth
<dael> Rossen_: Prop: optimizeQuality is replaced by smooth
<dael> ericwilligers: [missed]
<ericwilligers> optimizeQuality behaves the same as smooth, instead of behaving the same as auto.
<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
<ericwilligers> (Just like the existing spec text that optimizeSpeed behaves the same as pixelated)
<dbaron> yeah, +1 to Florian, I was going to raise the same thing once we got the resolutions down
<dael> Rossen_: For sure. but this is a technical decision for a particular property
<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
<dael> rossen: obj to optimizeQuality behaves the same as smooth ?
<dael> RESOLVED: optimizeQuality behaves the same as smooth