Re: Agenda request: image-rendering: crisp-edges

I know that the property defined in SVG is heavily used on SVG content. If CSS uses the same property that is fine for me. If CSS images adds new keywords and specifies what they mean in SVG that is fine for me as well.

But you can not remove keywords from an existing property because you don't like how SVG did it. They must be specified as well for backwards compatibility reasons.

I would be fine if you mark them as deprecated but mandatory.

Greetings
Dirk

Sent from my iPhone

On Apr 3, 2013, at 7:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Wed, Apr 3, 2013 at 4:53 AM, Tavmjong Bah <tavmjong@free.fr> wrote:
>> There appears to be a great demand among Inkscape users to be able to
>> upscale bitmaps without introducing blurring. Currently SVG has the
>> property 'image-rendering' which can take the values
>> 
>> auto | optimizeSpeed | optimizeQuality | inherit
>> 
>> The CSS Image Values and Replacement Content Module Level 4[1] uses the
>> same property name with the allowed values:
>> 
>> auto | crisp-edges | pixelated
>> 
>> This raises two questions. The first is the appropriation by CSS of the
>> property with different values from SVG
> 
> I did this for a few reasons:
> 
> 1) The existing names are SVG-style camelCase, which we avoid in CSS.
> This is only a minor thing, but still.
> 2) The names are instructions to the user agent, which are rarely
> going to be useful outside of a controlled environment.  Telling the
> UA to "optimize speed" because it's slow on your workstation is silly
> in 2 years when everyone has better computers, while telling it to
> "optimize quality" because it looks better and runs fine on your
> machine is silly when someone views your page on their phone.  It's
> much better to handle this kind of thing by expressing intents - what
> qualities are useful to preserve when you perform scaling.  That's
> what the current values do.  As long as the UA respects the intent of
> the keyword, they can do what they like otherwise.
> 
>> and the second is that it would
>> be desirable for SVG to allow the new proposed values from CSS.
>> 
>> Some browsers (Mozilla, Opera) already support the value 'crisp-edges'
>> for HTML (but not SVG). Webkit supports the concept but with a different
>> value name. IE supports the concept with a different property.[2]
> 
> There's no reason it can't be supported today - the definition isn't
> in any way limited to HTML elements.
> 
> ~TJ
>

Received on Wednesday, 3 April 2013 15:07:01 UTC