W3C home > Mailing lists > Public > www-style@w3.org > December 2010

Re: [css3-images] image-rendering property for contrast-preserving image upscaling

From: David Singer <singer@apple.com>
Date: Thu, 2 Dec 2010 10:05:26 -0800
Cc: Chris Lilley <chris@w3.org>, James Robinson <jamesr@google.com>, robert@ocallahan.org, www-style list <www-style@w3.org>, public-fx@w3.org
Message-Id: <43108980-E5A8-4CBE-AC6B-CFFF0C211C8C@apple.com>
To: Tab Atkins Jr. <jackalmage@gmail.com>

On Dec 2, 2010, at 9:00 , Tab Atkins Jr. wrote:

>> Deprecated because ...
> They don't communicate good intents.  The UA should *always* be trying
> to optimize both quality and speed.  Letting the author, for example,
> choose optimizeSpeed because of the UA not properly throttling itself
> right now means that the image will continue to use a fast/ugly
> scaling algorithm on better/future devices where it's no longer
> necessary to force a fast algorithm.  This is the same reason HTML
> doesn't expose similar controls for <video>, despite requests for such
> a feature.
> I'd prefer to just say that both of those values are aliases for
> 'auto', which captures the meaning that we want.
> optimize-contrast, on the other hand, communicates something important
> that the UA *cannot* automatically choose between; using a scaling
> algorithm from the "smoothing" family or "contrast-preserving" family
> makes a *huge* difference, and there are distinct classes of images
> that should be scaled with one or the other.

I agree with Tab.  I've made this mistake enough times, myself.  Don't say what you want from the UA (everyone wants the moon), tell the UA what the characteristics are (which you know and can be clear about), and let it do the best it can.  "I prefer quality over speed" looks, at first blush, useful, until you ask "well, how slow can I be?  how much quality do you need?".  OTOH, knowing that the image characteristic falls into one of a few classes can indeed let the UA make intelligent decisions.

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 2 December 2010 18:06:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:41 UTC