- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Mon, 29 Jul 2013 12:10:25 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
Le 26/07/2013 18:41, Tab Atkins Jr. a écrit : > On Fri, Jul 26, 2013 at 10:21 AM, Simon Sapin<simon.sapin@exyr.org> wrote: >> Le 26/07/2013 17:56, Tab Atkins Jr. a écrit : >>> 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. >> >> Your first point also applies to user zoom, especially with mobile-style >> panning zoom. What does "snap" mean in this context? > No, mobile pinch-zoom is a distinct type of zoom. We need to > formalize these concepts within CSS, as they're being formalized in > the back-end ad-hocly right now. > > The relevant type of zoom is the one that changes the viewport size. > This changes a bunch of the layout, so it's okay for images to have a > different intrinsic size. Ok. So, to sum up: * Transforms should not affect 'snap'. This makes 'snap' useless on transformed images, but that seems better than the alternative. * "Desktop-type" zoom that changes the size (in CSS units) of the initial containing block should affect 'snap'. That’s fine because layout probably changes anyway. * "Mobile-type" zoom that does not change the size of the ICB should not affect 'snap'. IMO this makes 'snap' completely useless if the user is expected change the zoom level a lot. I’d rather have UAs ignore it in such cases than apply it in a way that only makes sense at one precise zoom level. -- Simon Sapin
Received on Monday, 29 July 2013 11:10:49 UTC