- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jul 2020 21:34:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Zooming/Panning per-element`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Zooming/Panning per-element<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5275<br> <fantasai> AmeliaBR: This has come up with work I've been doing, and zcorpan was reviewing, on standardizing map viewers<br> <fantasai> AmeliaBR: A map embed, where you move around the map on the screen and zoom in / out<br> <fantasai> AmeliaBR: There's no standard way to describe that behavior in specs<br> <fantasai> AmeliaBR: But it is a very common pattern, with common interaction patterns<br> <fantasai> AmeliaBR: Mouse behaves a certain way, touch behaves a certain wain<br> <fantasai> AmeliaBR: In addition to map viewers, also common for product photos on a retail site<br> <fantasai> AmeliaBR: data visualizations<br> <fantasai> AmeliaBR: Some things to think about..<br> <fantasai> AmeliaBR: two different aspects of typical pan+zoom impl<br> <fantasai> AmeliaBR: One is the UI and interaction patterns<br> <tantek> listens earnestly, to understand how "pan" is materially different from "scroll" in terms of the control that 'overflow' affords.<br> <fantasai> AmeliaBR: how the end-user indicates, by gestures or whatever, where they want to go and andzooming in / out<br> <fantasai> AmeliaBR: The other aspect is loading content, e.g. higher-resolution<br> <fantasai> AmeliaBR: From a CSS perspective, the are going to be two independent things to think about<br> <fantasai> AmeliaBR: Loading in separate content, have something similar to a MQ scoped to a particular container that has a zoom state<br> <fantasai> AmeliaBR: triggers picture sources or whatever<br> <emilio> q+<br> <fantasai> AmeliaBR: Basic prerequisite for that is to have a standardized way to describe pan + zoom<br> <TabAtkins> q+<br> <fantasai> AmeliaBR: Which as a lot of similarities to scrolling environments<br> <heycam> q+<br> <fantasai> AmeliaBR: but the standard actions are a little different, different translation of input<br> <smfr> q+<br> <fantasai> AmeliaBR: different established pattern of movement<br> <fantasai> AmeliaBR: Other thing is that you don't necessarily start at the beginning and scroll down, often starting in the middle<br> <fantasai> AmeliaBR: and usually not showing scrollbars<br> <fantasai> AmeliaBR: So established pattern of panning , semi-standardized<br> <fantasai> AmeliaBR: not always implemented in a way that is keyboard-accessible, or devices otherwise unique wrt inputs<br> <fantasai> AmeliaBR: So much easier for authors to have a standard way to switch into this mode, don't have to code up a lot of JS<br> <fantasai> AmeliaBR: and can make it more cross-platform and accessible<br> <tantek> interesting, Google Maps is a *mix* of infinite pan in the horizontal direction, while having blocking scrolling in the vertical direction!<br> <fantasai> AmeliaBR: No proposal yet, but wanted to bring up to CSSWG, is it something appropriate to address in CSS? Any opinions on how?<br> <fremy> q+<br> <astearns> ack emilio<br> <fantasai> emilio: I was chatting about this with some of the zooming folks in Gecko<br> <fantasai> emilio: Zooming and panning is limited to top-level content document<br> <fantasai> emilio: Depends on specific use cases you want to solve<br> <fantasai> emilio: Not enabling for iframes etc, is artificial limitation<br> <fantasai> emilio: Depending on set of use cases, documents already have all these APIs, visual viewport API etc.<br> <fantasai> emilio: allow authors to react to these things<br> <fantasai> emilio: depending on set of use cases, if enabling on iframes solves them, could be relatively easy to do<br> <fantasai> AmeliaBR: That's interesting. So describing it as the same pinch-zoom behavior that we have in most mobile browsers<br> <fantasai> AmeliaBR: but scoped to a specific elmeent<br> <fantasai> AmeliaBR: one thing there, I don't know enough about mobile a11y if there's standard mapping to keyboard controls for pinch-zoom view<br> <astearns> ack tantek<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: I think this is great and interesting<br> <chrishtr> q+<br> <fantasai> TabAtkins: especially on touch devices, interaction is similar wrt scroll vs pan<br> <fantasai> TabAtkins: but being able to opt into more pan+zoom interaction easily on desktop would be useful<br> <fantasai> TabAtkins: You said something about being media-query?<br> <fantasai> TabAtkins: Needs to be a property modifying how we handle overflow<br> <fantasai> TabAtkins: particularly because of wrapping behavior necessary for some cases<br> <fantasai> AmeliaBR: MQ thing was for the loading different resolution images<br> <fantasai> AmeliaBR: e.g. in a picture source<br> <fantasai> TabAtkins: Talking about level of detail<br> <fantasai> ?<br> <fantasai> AmeliaBR: Yes<br> <fantasai> TabAtkins: Level of detail is a much more complicated topic<br> <fantasai> TabAtkins: if we can separate from overflow interaction... it's much harder<br> <fantasai> AmeliaBR: Agree it's the next level, and first level would be to standardize pan-zoom interaction<br> <tantek> Yandex maps also only does (infinite) pan horizontally and (blocking) scroll vertically.<br> <fantasai> AmeliaBR: and zoom part of it, so long as it's exposed to authors so they can detect the desired level<br> <fantasai> AmeliaBR: that can be JS at first<br> <fantasai> AmeliaBR: and work on declarative way to do that as we go along<br> <fremy> q?<br> <fantasai> AmeliaBR: You brought up another point, tantek brought up too,<br> <fantasai> AmeliaBR: in some environments, such as maps, you want a wrap-around effect<br> <fantasai> AmeliaBR: if you scroll to the end, scrolls back to the beginning; spherical or cylindrical coordinate system<br> <fantasai> AmeliaBR: Other areas in CSS where it might be useful, like an image gallery<br> <fantasai> AmeliaBR: where you scroll to the end, end up at the beginning<br> <fantasai> AmeliaBR: Again, slightly separate from panning interaction itself<br> <fantasai> AmeliaBR: but is also a relevant part of the discussions<br> <astearns> ack heycam<br> <fantasai> heycam: I think it's worthwhile thinking about this further<br> <fantasai> heycam: My one concern is that we know what the full set of requirements are around panning and zooming<br> <fantasai> heycam: so that we don't design a feature that goes 90% of the way, but the last 10% requires reimplementing everything<br> <fantasai> heycam: E.g. some JS things let you pinch-rotate the map<br> <fantasai> heycam: if not a good way to do that, they authors might feel like re-implementing everything<br> <tantek> oh yeah, there's also two-finger-tilt in some maps!<br> <fantasai> heycam: Might want to list what are the missing features, that doesn't allow doing maps online<br> <fantasai> heycam: what's missing/janky<br> <fantasai> heycam: so we know the design space<br> <astearns> ack smfr<br> <fantasai> smfr: Echo some of heycam's concerns<br> <fantasai> smfr: Differnet clients have different needs<br> <fantasai> smfr: some have very specific requirements<br> <fantasai> smfr: anything we make might not be enoug, end up using JS again<br> <fantasai> smfr: Maybe we should focus on primitives that ppl require to do this<br> <fantasai> smfr: one is always getting gestures right<br> <fantasai> smfr: sometimes it's vertical scroll, sometimes it's pinch-zooming, inconsistent<br> <fantasai> smfr: WebKit had some non-standard events like this<br> <fantasai> smfr: Differerent areas of the page with different zoom levels, could have confusion wrt MQ or something<br> <fantasai> smfr: Need to figure that out<br> <tantek> q?<br> <fantasai> AmeliaBR: Just answering to last bit about CSS transforms, that's how I picture it<br> <fantasai> AmeliaBR: similar to CSS transforms or SVG viewbox, where it is a localized transform that gets added to that stack<br> <fantasai> AmeliaBR: That's how it was originally specced for SVG, that there would be a user nteraction that ends up changing the viewbox transform<br> <fantasai> AmeliaBR: that never got implemented in browser versions of SVG<br> <Rossen_> Q?<br> <astearns> ack dbaron<br> <Rossen_> q+<br> <fantasai> dbaron: I agree with a lot of the concerns brought up so fora<br> <fantasai> dbaron: a lot of panning and zooming is complex behavior<br> <fantasai> dbaron: as mentioned<br> <fantasai> dbaron: Also many sites change fragment of the URL in response to panning and zooming, so you can bookmark where you are<br> <fantasai> dbaron: An interesting thing to investigate, if we do or don't want to do something, requires a more concrete proposal about something to add<br> <fantasai> dbaron: and an analysis of how that thing is useful for all the consumers that are out there<br> <tantek> q?<br> <astearns> ack fremy<br> <fantasai> fremy: I think that's similar to what other said before<br> <fantasai> fremy: map use case, it's unlikely to desire to do in CSS<br> <tantek> could see pan as an alternative to scroll, meaning it wraps around in that dimension. that seems like a nice incremental enhancement.<br> <fantasai> fremy: When you start to do zooming, dimensions of pixel changes over time<br> <fantasai> fremy: with dynamic contents<br> <fantasai> fremy: it's easier to adapt yourself as zooming<br> <fantasai> fremy: than to back-propagate to elements shown<br> <fantasai> fremy: For use case for maps, highlly unlikely anyone would prefer CSS solution<br> <fantasai> fremy: but other cases<br> <fantasai> fremy: if you include PDF or SVG documents<br> <fantasai> fremy: Sometimes it's really nice to be able to zoom on them<br> <fantasai> fremy: and these contents do not react ot gestures<br> <fantasai> fremy: so more reasonable use case to focus on these<br> <fantasai> fremy: so you really want to provide view on fixed contents<br> <fantasai> fremy: for maps, need to know where user is, fetching data to get new info, new tiles, etc.<br> <fantasai> fremy: I'm not sure it would work for a world map to fit in CSS pixels<br> <fantasai> fremy: At least for dynamic use cases, seems highly unlikely for CSS to provide a solution<br> <fantasai> fremy: so if working on that, suggest to focus on static use cases<br> <fantasai> fremy: you want the effect, but don't want to include an entire library<br> <astearns> ack chrishtr<br> <fantasai> chrishtr: In addition to what fremy said, about dynamic scenario, where devs want top optimize pixels at different zoom levels and to ??<br> <dbaron> Example of the pan/zoom results being in the URL (in a very common format for putting it in the URL): https://www.openstreetmap.org/#map=18/43.45397/-80.49867<br> <fantasai> chrishtr: a lot of maps these days are drawn with WebGL anyway, I don't think this approach would work with WebGL<br> <Rossen__> q/<br> <Rossen__> q?<br> <fantasai> AmeliaBR: Could work if you have a top-level DIV which maintains interaction with users, and passes things as events<br> <fantasai> AmeliaBR: just as many things use position on scrollbar to trigger things, but still using normal scrolling<br> <fantasai> chrishtr: common gestures across sites would be useful<br> <astearns> ack Rossen__<br> <fantasai> Rossen__: I think most everything was said already<br> <fantasai> Rossen__: Want to underline here, still the motivation or use case here involves quite a bit of complexity<br> <fantasai> Rossen__: zoom as a gesture, as a capability of a presentation system, is a very overloaded behavior, that has many differnet parts that more often than not apps are hooking into<br> <fantasai> Rossen__: initiation of zoom vs when it is already steady<br> <fantasai> Rossen__: visual zoom, layout-affecting zoom<br> <fantasai> Rossen__: semantic zoom, going through levels of different categories of app logic<br> <fantasai> Rossen__: loads / unloads resources<br> <fantasai> Rossen__: so this is also a type of zoom<br> <fantasai> Rossen__: Tab summarized as, what are primitives we're missing here?<br> <fantasai> Rossen__: when we thought about this in the past<br> <fantasai> Rossen__: and attempted to extend zoom for application developers<br> <fantasai> Rossen__: the main point was, what are the primitives that a platform such as CSS needs to provide<br> <fantasai> Rossen__: capabilities and observability of it<br> <fantasai> Rossen__: to extend that we do to today, quite far on this journey<br> <fantasai> Rossen__: can observe types of transforms applied, etc.<br> <fantasai> Rossen__: but you also mentioned something interesting<br> <fantasai> Rossen__: around a11y, and this being able to help a11y<br> <TabAtkins> q+<br> <fantasai> Rossen__: whad do you mean by that?<br> <astearns> ack Rossen__<br> <fantasai> Rossen__: is that the ability to use zoom as an intent? or are there experiences broken today?<br> <TabAtkins> ack Rossen_<br> <tantek> gmap-pedometer is also horizontal pan, vertical scroll<br> <fantasai> AmeliaBR: Specifically about existing author code and libraries aren't necessarily working well with different ways ppl interact with their computer<br> <fantasai> AmeliaBR: pan and zoom via keyboard controls is very opaque and inconsistent from site to site<br> <fantasai> AmeliaBR: just by standardizing it, we could move towards the browser controlling that standard interaction<br> <fantasai> AmeliaBR: and making sure it's accessible for all the ways ppl interact with their computre<br> <fantasai> AmeliaBR: being able to zoom is also an a11y issue, but not necessarily going to line up with author's decision that certain content is zoomable<br> <fantasai> Rossen__: Usually what we specify here, we specify differnet modality of input<br> <fantasai> Rossen__: and capability of apps to provide the zoom experience or bheavior<br> <fantasai> Rossen__: whether [lists input actions]<br> <fantasai> Rossen__: reality is these will differ vastly between capabilities of device<br> <fantasai> Rossen__: and standardizing on these types of gestures or higher-level intents<br> <tantek> really dislikes when you're using scroling gestures to scroll down a page, then you run into a full width map and your page stops scrolling, and the map starts zooming. What a disaster of overloading the same gesture to do/mean different things. Can we fix that? or at least not create something (primitives) that would make it worse?<br> <fantasai> Rossen__: will be more troublesome than if we identify primitives missing in the platform to allow awareness of this thing happening<br> <fantasai> TabAtkins: I strongly agree with idea that this would be really useful for a11y, because not relying on bespoke and incomplete JS solutions to a very common modality<br> <fantasai> TabAtkins: as something becomes common, if it's addressed by random JS solution, won't be accessible to ppl not having same setup as JS author<br> <fantasai> TabAtkins: captureing, as Amelia says, that this is meant to be a pan/zoom thing<br> <fantasai> TabAtkins: As dbaron says, we need a concrete proposal<br> <fantasai> TabAtkins: I propose two parts<br> <tantek> +1 TabAtkins<br> <fantasai> TabAtkins: 1. new generic property that switches into pan+zoom mode<br> <fantasai> TabAtkins: 2. A gesture-based JS approach, so you can hook that, and then roll your own pan+ zoom<br> <fantasai> TabAtkins: so you can roll your own, as ppl currently do with 'overflow: hidden'<br> <fantasai> TabAtkins: So, CSS side that does things automatically as long as you do simple thing<br> <smfr> not scroll events (they are reactive, not prescriptive)<br> <fantasai> TabAtkins: and JS side that standardizes pan+zoom gestures, and lets ppl hook that to do further stuff<br> <smfr> say input events like mouse and wheel<br> <fantasai> TabAtkins: build on top of mouse/keyboard gestures etc.<br> <astearns> ack TabAtkins<br> <fantasai> AmeliaBR: That's a useful breakdown<br> <tantek> was tilt explicitly excluded or just not brought up?<br> <TabAtkins> not brought up<br> <tantek> e.g. Google maps on a touch device, two finger up/down gesture will tilt the map up/down<br> <fantasai> AmeliaBR: Also need to take into consideration what exactly overflow would look like, all dfiferent things that need to be considered.<br> <fantasai> AmeliaBR: semantic gesture events, for pan+zoom<br> <fantasai> AmeliaBR: One question, who would be standardizing group for adding new events?<br> <fantasai> TabAtkins: I think WICG until it gets picked up by DOM?<br> <fantasai> fremy: But we do have CSS events too<br> <fantasai> smfr: We also have scroll events<br> <fantasai> smfr: You want all the input events to be defined in the same place<br> <TabAtkins> ScribeNick: TabAtkins<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: In addition to capturing the gestures tha twoudl correspond to pan/zoom/etc<br> <tantek> pan / zoom / tilt / rotate<br> <TabAtkins> fantasai: I think ifyou had pan/zoom mode for overflow, we have currently a lot of APIs for getting the current scroll position and direct a widget to go to that position<br> <TabAtkins> fantasai: You'd probably want analogous methods that would let you do all the manipulations in scripts<br> <tantek> +1 fantasai, zoom level equivalents to scroll settings<br> <tantek> The only request I have is to include tilt & rotate in pan & zoom considerations / designs<br> <fantasai> s/do all the manipulations in script/do the same things in pan+zoom, e.g. get zoom level or set zoom level/<br> <fantasai> ScribeNick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5275#issuecomment-664650327 using your GitHub account
Received on Monday, 27 July 2020 21:34:17 UTC