Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add post on image-rendering CSS property #229

Open
stuartpb opened this issue Jan 11, 2013 · 10 comments
Open

Add post on image-rendering CSS property #229

stuartpb opened this issue Jan 11, 2013 · 10 comments

Comments

@stuartpb
Copy link

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

@nimbupani
Copy link
Member

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

@stuartpb
Copy link
Author

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
Copy link
Member

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

@stuartpb
Copy link
Author

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
Copy link
Member

arthurvr commented Dec 1, 2014

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

@stuartpb
Copy link
Author

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

@stuartpb
Copy link
Author

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
Copy link
Member

arthurvr commented Feb 7, 2015

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

@stuartpb
Copy link
Author

stuartpb commented Feb 8, 2015

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

@stuartpb
Copy link
Author

stuartpb commented Feb 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants