- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Mon, 29 Jul 2013 17:54:24 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
Le 29/07/2013 17:33, Tab Atkins Jr. a écrit : > On Mon, Jul 29, 2013 at 4:10 AM, Simon Sapin <simon.sapin@exyr.org> wrote: >> 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. > > If you're designing a mobile site and care about the resolution of > your images, you should be setting the zoom level to 1 anyway. Users > are *not* generally "expected to change the zoom level a lot" - when > that's happening, it's because they're using a site designed solely > for desktop without any thought given to mobile. > > Additionally, as I stated, these constraints are exactly the same as > what we want to expose for <canvas>. My point is, "number of device pixels" (and its relationship to CSS units) needs a much more precise definition than what’s currently in css-images-3, and we may want to tweak that definition with respect to transforms, zoom in various situations, etc. I don’t have a strong opinion on the details of this definition, as long as it’s well-defined. Do you have a wording to suggest? -- Simon Sapin
Received on Monday, 29 July 2013 16:54:48 UTC