On Fri, Feb 1, 2013 at 5:56 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> The snap keyword for image-resolution is defined as:
>
>> If the "snap" keyword is provided, the computed ‘<resolution>’ (if
>> any) is the specified resolution rounded to the nearest value that
>> would map one image pixel to an integer number of device pixels. If
>> the resolution is taken from the image, then the used intrinsic
>> resolution is the image's native resolution similarly adjusted.
>
> <resolution> values of image-resolution count image pixels per CSS pixels.
> snap is about image pixel per device pixels. CSS transforms can change the
> ratio between CSS pixels and device pixels[1].
>
> Therefore, should `snap` be affected by transforms? If this is done at
> computed value time, do implementations need to have accumulated
> transformation matrices that early?
>
>
> [1] Although I’m not sure that ratio still makes sense if the transformation
> has any skew component, a rotation component that is not a multiple of 90°
> around the Z axis, or a scale component that does not preserve aspect
> ratios.
I don't think it should. For one, this would mean that the intrinsic
size of an image changes as you transform it, which is clearly not a
good result.
For two, as you note, only a limited set of transforms can reasonably
affect this - what happens if you're just using "scale(x)", and then
change to "scale(x) skew(y)" on hover? Ignore the entire transform
effect? Filter the transform for things we can affect? What if the
skew() is instead before the scale()?
Plus, for the purpose of drawing into a <canvas>, we're choosing to
report the native screen resolution * zoom level, but aren't paying
attention to transforms. This should work similarly.
~TJ