Support image-rendering

[yisibl]

Specs(CR)

http://dev.w3.org/csswg/css-images-3/#the-image-rendering

The standard value:

• auto
• crisp-edges
• pixelated

The old value

optimize-contrast’ = ‘crisp-edges’

Changed the ‘optimize-contrast’ value to ‘crisp-edges’, and rewrote the description slightly to reduce confusion in what it does.
http://www.w3.org/TR/2011/WD-css3-images-20110712/#changes

img {
  image-rendering: -webkit-optimize-contrast;/* Webkit (non-standard naming) */
  image-rendering:          -moz-crisp-edges;         /* Firefox */
  image-rendering:            -o-crisp-edges;         /* Opera */
  -ms-interpolation-mode:   nearest-neighbor;  /* IE (non-standard property) */
  image-rendering:               crisp-edges;
}

optimizeSpeed and optimizeQuality

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 auto, and authors must not use them.

MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering
More:

• http://stackoverflow.com/questions/20678639/image-rendering-crisp-edges-vs-pixelated

[ai]

I send PR to Can I Use: Fyrd/caniuse#864

[ai]

We will not support -ms-interpolation-mode because (as I understand) IE uses different values.

[ai]

Done ai/autoprefixer-core@f59b70d

[simevidas]

I don’t understand the difference between crisp-edges and pixelated. From reading the spec, both seem to preserve pixels. Could you explain?

[ai]

Here is good explanation: http://stackoverflow.com/a/25278886

[simevidas]

@ai Thanks. According to that explanation, crisp-edges reduces pixelation, while pixelated does not reduce it. This is however, not what I’m seeing when testing -webkit-optimize-contrast (in Safari/iOS 8) and -moz-crisp-edges (in Firefox). In both cases, the pixels are completely preserved. Live demo is here.

I’m not happy with the current state of the spec and browser implementations. If things were more coherent, web developers could start using a single property for preserving pixels while up-scaling (this will become possible cross-browser soon as my demo shows), with Autoprefixer “filling in the blanks”. But with this dual-value approach, web devs will have to continue manually writing -ms- for IE and pixelated for Chrome to achieve this (or use a custom mixin).

[stuartpb]

The way I would sum it up (as I'm drafting in h5bp/html5please#229): The valid values for image-rendering are auto and pixelated (and inherit). crisp-edges is ambiguous, poorly-defined, unlikely to ever make it into two separate implementations, and probably going to be deprecated as another synonym for auto (like optimizeSpeed and optimizeQuality were) or pixelated (which most implementations redundantly tried to do originally). Everything else is already a synonym for auto.

Curiously, -ms-interpolation-mode: nearest-neighbor, as implemented by older versions of IE, _is_ correctly analogous to image-rendering: pixelated; despite using different names, it has the exact same meaning.

[simevidas]

@stuartpb crisp-edges is a valid value according to the latest editor’s draft. If you think that it should go away, may a suggest starting a discussion at Specifiction (“image-rendering - do we need both pixelated and crisp-edges?”)? The spec’s editor, Tab, frequents that forum, so he may outline his views there too.

[stuartpb]

It's not that I want crisp-edges to be deprecated (this StackOverflow answer has made it a bit more clear what `crisp-edges is supposed to mean). It's that, based on the way it's been handled historically across implementations, deprecating the name (and maybe starting again) is the only thing I can actually see happening.

Right now, there's nothing good you can expect from using crisp-edges as a property of image-rendering: Going by the MDN examples on my Windows machine, Chrome seems to make images blurrier when upsampling, and uses it to mean "nearest neighbor" for downsampling. Meanwhile, Firefox uses it to mean "nearest neighbor" for everything (and practically uses "nearest neighbor" for downsampling for auto, too). Changing it to mean anything else is liable to break any existing use of the property.

[Tavmjong]

The CSS Images editor's draft now has an image that demonstrates the difference between pixelated and crisp-edges.

[matt-curtis]

Currently autoprefixer spits out:

autoprefixer: my.css:8:3: There is no browsers with crisp-edges rendering support.
Maybe you mean pixelated?

Shouldn't crisp-edges be converted to its cross-browser equivalent (as detailed above)?

[simevidas]

@matt-curtis crisp-edges and pixelated produce different results (see image in spec, linked above). pixelated can be supported cross-browser using various prefixed values, including -moz-crisp-edges, and Autoprefixer does that. crisp-edges is not supported in any browser AFAIK, so Autoprefixer doesn't do anything with it.

[matt-curtis]

I'm a little confused. In Webkit (Safari/Chrome) -webkit-optimize-contrast and pixelated do different things, and crisp-edges = -webkit-optimize-contrast, right?

[simevidas]

@matt-curtis I’ve tested my demo (“The result” image) on an iPhone. -webkit-optimize-contrast behaves like pixelated, in that pixels are perfectly preserved. Notice in the spec, how crisp-edges does not preserve pixels; instead it aims to produce a crisp look where pixels are not visible.

[matt-curtis]

I'm testing in Chrome. There, -webkit-optimize-contrast and pixelated behave differently.

pixelated:

-webkit-optimize-contrast:

[simevidas]

@matt-curtis Chrome no longer supports -webkit-optimize-contrast, now that it has pixelated. The former is needed for Safari and WebKit. Test -webkit-optimize-contrast in Safari to see how it behaves.

[MacyEleanorMay]

My trouble is that I read the word standard ALL over the place when it comes to the attributes for this so-called proposed 'standard'. Each and every browser out there accepts different values and respond totally different to those exact same values. This is non-serious and should def. not be labelled a standard. CSS has no standards. At least no one (Browsers) are adhering to them ! Which basically voids the terminology. Wishful thinking would be more appropriate. Standard NO!

In regards to Auto... Automatic implies that the browser should/can choose what is best depending on its intelligence... The keyword AUTO - singlehandedly - voids the use for the image-rendering property in the first place... I take that the browser ALREADY decides how to best render any given image.. WITHOUT me or anyone else having to specify the image-rendering prop. at all. So attributing the keyword auto to this property is only adding to the confusion.

This is SO simple in reality.

Q) Why would a developer WANT to use image-rendering in the first place ?????
A) To control HOW the UA renders the imagery.

Q) How Much control does a developer gain by using a setting called AUTO ?
A) A 3rd grader could answer this question !!! NONE - he relinquishes it !

Instead of breaking your heads with terminology - IMO you would be better off just dubbing the three options with Mode 1, Mode 2, Mode 3. Optimize Contrast, Crisp Edges are adjectives subject to interpretation and highly misleading when it comes to graphics ! At least the word contrast in common terms is NOT referring to the sharpness of the edges. And Crisp Edges sounds like something NOT in an image. Dub the Attributes for the people who USE them not the people who PROGRAM / Invent them!

No wonder the web is such a mess !

[simevidas]

@AXXOrganic Autoprefixer currently handles only the pixelated value from the spec. As far as I can tell, running image-rendering: pixelated through Autoprefixer produces a set of properties which ensure that the image is rendered in accordance with the spec, in all browser engines. The other two values, auto and crisp-edges are not handled by Autoprefixer, due to their lack of support in browsers. This is an issue with browsers, not Autoprefixer.