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. > It seems that browser zoom/changing the device pixel ratio should not be affected by 'snap'. This is a very confusing property. Shouldn't there be a reference to device pixel ratio? > > * "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 19:40:47 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC