- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 01:35:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations?] Proposal: Add overscroll gestures with ability to reveal elements`. <details><summary>The full IRC log of that discussion</summary> <fantasai> www-archive@w3.org<br> <vmpstr> thanks<br> <TabAtkins> flackr: many apps have swiping gestures to pull in components<br> <TabAtkins> flackr: often a directional meaning, menu on left, etc<br> <TabAtkins> flackr: in photos, swipe down to dismiss current photo<br> <TabAtkins> flackr: common thing devs want to do, they're usually handling this with events<br> <TabAtkins> flackr: we think this is very similar to scrolling in UX tho<br> <TabAtkins> flackr: movement of finger usually corresponds to movement of a UI component. often chained on a scrolling experience. we already have scroll-snap to talk about sticking<br> <TabAtkins> flackr: so we want to explore building this declaratively as an interaction<br> <TabAtkins> flackr: have a couple of ideas<br> <TabAtkins> flackr: could be CSS or html<br> <TabAtkins> flackr: the core thinking is it would be done with an ancestor scrolling area<br> <TabAtkins> flackr: you have content, when yous croll past it you pull in other UI<br> <TabAtkins> flackr: this creates a natural interaction where you can still access all the content in your scroller, then pull further to get the extra UI<br> <TabAtkins> flackr: the extra UI needs to be in one of these "overscroll areas"<br> <TabAtkins> flackr: so our proposal lets you say "my menu wants to be in this named overscroll area"<br> <vmpstr> https://docs.google.com/presentation/d/1J7RrjKQQCuqLjxTOTvGWoGmxq2FzVvL00YpEczaRUUo/edit?slide=id.p#slide=id.p<br> <TabAtkins> flackr: [shows example of CSS]<br> <TabAtkins> flackr: I mentioned this feels natural to integrate with scorlling<br> <TabAtkins> flackr: looking at maps, same action first scrolls in the sheet, then initiates overscroll action to pull in extra content<br> <TabAtkins> fantasai: [question about how slide 7 example is interpreted]<br> <TabAtkins> fantasai: what would it mean to say "right: 50%"?<br> <TabAtkins> flackr: it would be 50% in view<br> <TabAtkins> fantasai: so is the 'right' property what makes it on the left? if I set 'left: 10px; right: 10px;'?<br> <TabAtkins> flackr: then there's no overscroll content<br> <noamr> q+<br> <keithamus> q+<br> <TabAtkins> [more qs trying to figure out exactly what the layout model is here]<br> <wendyreid> q+<br> <TabAtkins> flackr: we're open to ideas on how to do it better<br> <emilio> q+<br> <TabAtkins> fantasai: what are the use-cases for multiple overscroll into same position?<br> <noamr> q-<br> <TabAtkins> vmpstr: top bar, then pull to refresh after that<br> <TabAtkins> vmpstr: you keep going and chain into higher levels<br> <TabAtkins> fantasai: how do you know which one is scrolled to first?<br> <TabAtkins> vmpstr: [looks at slide] based on scroll areas, they nest<br> <TabAtkins> vmpstr: based on order of the names in 'overscroll-area'<br> <adamargyle> q+<br> <TabAtkins> flackr: I have demos based on regular scrollers so you can playl with it<br> <noamr> q+<br> <TabAtkins> flackr: we want to make this easier to build<br> <TabAtkins> flackr: [explains the demos]<br> <TabAtkins> flackr: swipe to dismiss has overscroll in three directions<br> <ydaniv> q+<br> <TabAtkins> flackr: for any of these, we want to make sure there's a way to access the content when you're not on a swipe able device<br> <TabAtkins> flackr: some thoughts are based on what people do today in native apps or the web<br> <TabAtkins> flackr: maybe if one element creates the area, that element's label can describe the area<br> <TabAtkins> flackr: saying "swipe in X direction, you active this component". or maybe it's a button.<br> <TabAtkins> flackr: maybe a generic announcement about components.<br> <TabAtkins> flackr: on iOS there's a specific announcement about pull-to-refresh<br> <TabAtkins> flackr: scroll into view should do what you expect, bringing the area into view<br> <kizu> q+<br> <TabAtkins> flackr: a benefit for doing this in HTML is there's a more natural semantic meaning for the area to express<br> <TabAtkins> flackr: but there is a pretty tight CSS coupling regardless<br> <TabAtkins> flackr: many extensions possible. overlay a backdrop to hide content, so a pseudo for that<br> <TabAtkins> flackr: some cases where you want to push content out of view vs overlay content, want a switch<br> <TabAtkins> flackr: if you interact with the content you usually want to dismiss the overscroll area, need to define what would cause this<br> <TabAtkins> flackr: and some physics things to get right. scrolling is sometimes too easy to engage, maybe some stickiness<br> <astearns> ack kizu<br> <TabAtkins> keithamus: looks cool and well motivated<br> <astearns> ack kei<br> <TabAtkins> keithamus: difficult to do today<br> <TabAtkins> keithamus: curious, a lot of actions would need to have an equivalent button. a lot of demos show that<br> <astearns> q+ kizu<br> <TabAtkins> keithamus: like menu has a button as well<br> <TabAtkins> keithamus: since engineers will author a button anyway, wonder if we can express this using those button relationships<br> <TabAtkins> keithamus: won't always have a button, but could imagine pull-to-refresh where ethe overflow content itself is the button<br> <TabAtkins> keithamus: another rpoint, you talk about aria announcements<br> <TabAtkins> keithamus: not entirely sure that's necessary (but encourage reaching out to aria), but do think it's very important to get focus right<br> <TabAtkins> keithamus: curious about semantics of that<br> <TabAtkins> keithamus: abridged: scrolling gestures need an equivalent button, and focus is very important, maybe the most important a11y thing<br> <TabAtkins> keithamus: also, overscroll-for in HTML shoudln't have a dash<br> <astearns> ack wendyreid<br> <TabAtkins> wendyreid: this is very cool, reviewed it during breakout this week<br> <dbaron> q+ to reply to keith with some context about snap-to-activate<br> <TabAtkins> wendyreid: I think this presents some concerns about a11y, most have been identified. but also opportunities to make things a lot better<br> <TabAtkins> wendyreid: a challenge, already in native, is to navigate with a screen reader, you have to go thru all the content. bottom nav you have to scroll all the way down.<br> <TabAtkins> wendyreid: so I think this gives us the oppo to make shortcuts<br> <TabAtkins> wendyreid: something to consider might be - an aria prop called 'aria-flow-to' that gives alternate nav<br> <TabAtkins> wendyreid: maybe under implemented because it "sounds good" but unclear how to use it<br> <dbaron> context for my future comment: snap-to-activate explainer is at https://github.com/WICG/declarative-partial-updates/blob/main/snap-to-activate-explainer.md<br> <TabAtkins> wendyreid: but yeah, this definitely sounds like should be in html<br> <TabAtkins> wendyreid: really hard when things get abstracted away, when trying to debug this stuff.<br> <astearns> ack emilio<br> <TabAtkins> emilio: a few qs<br> <TabAtkins> emilio: how does this compare to native APIs?<br> <TabAtkins> emilio: do you have a quick answer? if not we can chat separately.<br> <astearns> if native equivalents have accessibility affordances this would also be useful input<br> <wendyreid> s/'aria-flow-to'/'aria-flowto'/<br> <TabAtkins> flackr: my understanding is the native approach is based on the toolkit, the toolkit usually handles things<br> <TabAtkins> noamr: we researched this - the layout is different on native. overflow doesn't exist the same way. instead it creates a stack, can stack to the left and right, up and down, above and below<br> <TabAtkins> noamr: the whole model is this stacked transparencies, very different from how CSS works<br> <TabAtkins> noamr: but the underlying concept is chained scrollers, and that's the same as css<br> <TabAtkins> flackr: in manyc cases, you need to bea ble to access the scrolled content first before you pull in a sidebar<br> <TabAtkins> emilio: in your demos you use scrollers, you can see the scrollbars moving around<br> <TabAtkins> emilio: so these things don't contribute to scrollable overflow, they're in this overscroll area that you can't normally scroll to...?<br> <TabAtkins> flackr: they're in the scrollable overflow of an ancestor *pseudo-element*<br> <TabAtkins> flackr: the dev wont' see an element with the scroll offset<br> <TabAtkins> emilio: okay so an anonymous scroller<br> <TabAtkins> emilio: is that a problem - I wonder how that interacts with the scroll APIs.<br> <TabAtkins> emilio: if I scrollIntoView something in the sidebar, it needs to focus and scroll in anonymous views, but there's no scroll event<br> <TabAtkins> flackr: ah, forgot to mention we do need to define events for this. because there's implicit snapping, there will be events exposing some of the details<br> <TabAtkins> emilio: ok. a bit tricky to figure out how much is done magically with anonymous boxes and custom events, or an HTML element with some default styles... I dunno<br> <TabAtkins> emilio: just a bit worried about a lot of anonymous magic that authors need to udnerstand<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <keithamus> q?<br> <TabAtkins> emilio: just my first gut feeling is a stacked nav element in HTML, maybe<br> <adamargyle> https://codepen.io/argyleink/pen/gOzPYOj (fwiw, the OS does not offer a button, per Keith's comment, and does have 1 hidden scrollbar, per emilio's comment)<br> <TabAtkins> astearns: lets' take this as input<br> <astearns> ack adamargyle<br> <TabAtkins> adamargyle: posted a link to exploration I did myself, recreating Android ecosystem, very swipey<br> <TabAtkins> adamargyle: one hidden scrollbar, some exposed ones<br> <TabAtkins> adamargyle: and a button, not common in OSes but it feels nice<br> <TabAtkins> adamargyle: I've done research on my own on gesture interfaces, run in script<br> <TabAtkins> adamargyle: have a q about axis locking<br> <TabAtkins> adamargyle: in Chrome scrolling is very axis locked usually<br> <TabAtkins> adamargyle: but swipe to dismiss image gesture is pretty omni-directional<br> <TabAtkins> adamargyle: script is often used for the customization people want, for physics and smoothness<br> <TabAtkins> adamargyle: I was curious about how much scroll-snap was used, it was a lot in my demos<br> <TabAtkins> adamargyle: especially scroll-snap-stop<br> <TabAtkins> adamargyle: interaction with scroll chaining, which doesn't always stop<br> <TabAtkins> adamargyle: is there gonna be some kind of overscroll-stop?<br> <TabAtkins> adamargyle: also good to hear about events<br> <TabAtkins> adamargyle: there was a proposal the other day that was snap-to-tap [?????]<br> <TabAtkins> adamargyle: I tap something, that takes it a snap target. noamr presented a swiping that [did something else]<br> <TabAtkins> adamargyle: is my focus cursor going to discover these areas?<br> <TabAtkins> adamargyle: also, semantic element. with responsive nature of web, difficult because this is very mobile centric<br> <ntim> +1 to this being mobile central<br> <TabAtkins> adamargyle: in CSS you can do all this on demand, only when needed<br> <ntim> mobile centric*<br> <astearns> ack noamr<br> <TabAtkins> noamr: want to reiterate that we see this as styling, progressive enhancement. shouldnt' change the semantic nature of your page<br> <TabAtkins> noamr: so this is tied strongly to CSS. a11y challenges, provide hooks to that. might match *with* an HTML semantic, "this action is an overscroll action", action is in HTML but where it goes to is in css<br> <astearns> ack ydaniv<br> <TabAtkins> noamr: want to start from that design principle<br> <TabAtkins> ydaniv: 1, I'd expect positioning to be done with anchor positioning, feels more natural<br> <TabAtkins> ydaniv: could anchor to the viewport<br> <astearns> (heads nodding)<br> <TabAtkins> ydaniv: 2, what are possibilities to change animation style, in and out? if it's scrolling I guess it's just scroll-snap and maybe a scroll timeline<br> <TabAtkins> ydaniv: but if people want to do other things, like coming in as a transparent container...<br> <TabAtkins> ydaniv: will that be how to customize?<br> <TabAtkins> flackr: back to Adam, we imagine these areas have an implicit snap to edge<br> <TabAtkins> flackr: lot of slight extensions to existing features. like don't think this should be axis locked. in a lot of overscrolls you're either constraining to one axis anyway, or just dont' want it locked<br> <TabAtkins> flackr: making it possible to un-lock a scroller in general is a feature we want to do<br> <astearns> ack kizu<br> <TabAtkins> kizu: big things were already mentioned by others<br> <TabAtkins> kizu: think for sure we do want to approach this from it being usable without the feature, for a11y, then this is enhancement<br> <TabAtkins> kizu: something I saw as a footgun is right:100% might be outside of scrollable area, not accessible otherwise<br> <TabAtkins> kizu: so need to think about how it would work by default<br> <wendyreid> +1 to testing it<br> <TabAtkins> kizu: I think snap is pretty good, make some areas and then choose them, when the feature is active you position them, but you can still navigate with mouse/etc<br> <TabAtkins> kizu: shouldn't rely on authors manually adding a button for non-swiping access, authors often don't add that stuff<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to reply to keith with some context about snap-to-activate<br> <dbaron> https://github.com/WICG/declarative-partial-updates/blob/main/snap-to-activate-explainer.md<br> <miriam> +1 kizu<br> <TabAtkins> dbaron: working on a separate but related feature called "snap to activate", which is connected to some of these use-cases<br> <TabAtkins> dbaron: at this point not as advanced, wasn't ready to present this week<br> <TabAtkins> dbaron: just discussing right now, not concrete proposal<br> <TabAtkins> dbaron: but did have a discussion with aria on Tuesday morning. I pasted the explainer<br> <TabAtkins> dbaron: to respond to some parts of Keith and Wendy's comments, there are pieces of here that do belong in CSS, and some that belong in HTML.<br> <TabAtkins> dbaron: I think snap to activate is probably mostly in HTML (but not fully worked out yet)<br> <TabAtkins> dbaron: still early, we've been actively talking to aria<br> <adamargyle> tap to snap example https://codepen.io/argyleink/pen/mdxqOYO<br> <TabAtkins> astearns: I wonder if this is something we should have a joint session with aria about<br> <wendyreid> +1 to joint session, maybe AGWG too?<br> <TabAtkins> astearns: probably better sooner than later<br> <TabAtkins> keithamus: maybe OpenUI too<br> <TabAtkins> astearns: let's keep noodling on this, thanks for the presentation<br> <TabAtkins> flackr: I think there will also be a lot of sub features that could launch separately, those will be separate issues<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12750#issuecomment-3530445478 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 01:35:54 UTC