W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-overflow] Consider adding new CSS primitive for per-element panning and zooming (for web maps) (#5275)

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
Message-ID: <issue_comment.created-664650327-1595885653-sysbot+gh@w3.org>
The CSS Working Group just discussed `Zooming/Panning per-element`.

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

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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:11 UTC