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

On Thu, Dec 2, 2010 at 6:17 AM, Chris Lilley <chris@w3.org> wrote:
> On Thursday, December 2, 2010, 3:04:27 AM, Tab wrote:
>
> TAJ> On Wed, Dec 1, 2010 at 5:55 PM, James Robinson <jamesr@google.com> wrote:
>>> On Wed, Dec 1, 2010 at 5:49 PM, Robert O'Callahan <robert@ocallahan.org>
>>> wrote:
>
>>>> I don't think we should introduce a new property. I think we should just
>>>> add new values to the image-rendering property. optimizeQuality and
>>>> optimizeSpeed should be deprecated.
>
>>> That sounds great to me.  I think we should also define image-rendering
>>> somewhere in CSS so authors know they can use it on non-SVG content.
>
> TAJ> Gimme a name for the new value and I'll add it to Image Values.
>
> Before unilaterally deprecating two SVG values and moving the definition of the property from SVG to CSS, it might be an idea to run that proposal by the SVG WG first, say in an FX telcon?

Don't worry, adding something to what is currently just an Editor's
Draft isn't a big step.  ^_^  Hopefully I can discuss it at the next
FX telcon.  (Is it next Monday?  If so, I'll be flying during the
call.  James'll have to attend for me or something.)


On Thu, Dec 2, 2010 at 6:15 AM, Chris Lilley <chris@w3.org> wrote:
> On Thursday, December 2, 2010, 2:49:09 AM, Robert wrote:
>
> ROC> I don't think we should introduce a new property. I think we
> ROC> should just add new values to the image-rendering property.
> ROC> optimizeQuality and optimizeSpeed should be deprecated.
>
> 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.

~TJ

Received on Thursday, 2 December 2010 17:01:51 UTC