Add post on image-rendering CSS property

h5bp / html5please

Graded Feature Support: Look up web technologies and find out if they are ready for use.

http://html5please.com/

MIT License

837 stars 265 forks source link

Add post on image-rendering CSS property #229

Open stuartpb opened 11 years ago

stuartpb commented 11 years ago

See https://developer.mozilla.org/en-US/docs/CSS/image-rendering

nimbupani commented 11 years ago

@stuartpb care to condense that into a pull request? I suppose it would be 'use' as a recommendation?

stuartpb commented 11 years ago

I would honestly peg it at "avoid".

The spec is vague on almost every behavior, with outstanding issues. Each major browser disregards large portions of the spec in its implementation:

None of the browsers listed implement "pixelated"
Gecko uses nearest-neighbor for downscaling with "auto"
WebKit's "-webkit-optimize-contrast" has no effect on the scaled checkerboard examples, uses nearest-neighbor for downsampling the hat, and uses some algorithm that appears to make the flowers blurrier for upscaling
Internet Explorer completely ignores the spec and uses its own non-standard (but unambiguous) "-ms-interpolation-mode"

Until the specification reaches a point where two major implementations can agree on a working behavior, I'd say it's not even ready to polyfill.

nimbupani commented 11 years ago

But what is the worst that can happen? It seems harmless enough & useful when supported? Or am I understanding this incorrectly?

stuartpb commented 11 years ago

The same worst that can happen with any other not-yet-ready specification: code that relies on a behavior that isn't widespread in the present and doesn't exist in the future. Look at what would have happened to anything targeting the "optimizeSpeed" value to use nearest-neighbor scaling (or even just to optimize speed) when that was part of the spec: the spec now says that it should be functionally equivalent to "auto", meaning it should use the slowest and blurriest scaling available.

arthurvr commented 9 years ago

Any update in here? PRs are always welcome...

stuartpb commented 9 years ago

I think Blink implemented "pixelated" a little while ago, let me review my tweets...

stuartpb commented 9 years ago

Okay, found it: https://twitter.com/stuartpb/status/505818369509965824

Chrome dashboard item: https://www.chromestatus.com/feature/5118058116939776 - part of Stable as of Chrome 40

Discussion about shipping image-rendering:pixelated in Firefox: https://groups.google.com/forum/#!topic/mozilla.dev.platform/0KYBjCdUMJw - at last mention in October, it sounds like a second-browser implementation is a fair way out due to Gecko's internal rendering architecture.

So, for now, I'd stick with "avoid", unless somebody can produce a decent image-rendering:pixelated polyfill for Firefox/IE (and maybe even Safari).

And I'd definitely add a note to avoid using the non-"pixelated" values (other than using "auto" to override a "pixelated" rule) until they stop being in flux (even though the latest spec is certainly leaps and bounds ahead of where it was 15 months ago).

arthurvr commented 9 years ago

k. Thanks for the explanation, @stuartpb. Would you mind doing a PR?

stuartpb commented 9 years ago

Let me check what the status of this is in autoprefixer, I feel like they addressed this sometime recently.

stuartpb commented 9 years ago

ping postcss/autoprefixer#367 Fyrd/caniuse#864