- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 26 Jul 2013 09:56:51 -0700
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: www-style list <www-style@w3.org>
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
Received on Friday, 26 July 2013 16:57:38 UTC