Proposal: overscroll way of accessing content

[vmpstr]

Hey all,

We'd like to propose a set of primitives for accessing content in overscroll areas of other elements. A motivating example would be a side menu that can slide in in response to either a button click or a scroll gesture.

Here's a more fleshed out explainer than this issue: https://github.com/vmpstr/htmldemos/blob/master/gestures/READMEv2.md

Happy to discuss this at a meeting

/cc @flackr

[css-meeting-bot]

The Open UI Community Group just discussed Proposal: overscroll way of accessing content, and agreed to the following:

• RESOLVED: land an explainer in OpenUI

The full IRC log of that discussion

<masonf> vmpstr: explainer is here: https://github.com/vmpstr/htmldemos/blob/master/gestures/READMEv2.md
<masonf> vmpstr: motivating example is side-menus that slide into view. Or there's a button to open it.
<masonf> scribe+
<masonf> vmpstr: more examples also. Presented at CSSWG at TPAC last week.
<masonf> ...received feedback: because of semantics, this belongs in HTML. A11y is important. Don't use hyphens.
<masonf> ...new explainer to incorporate that.
<masonf> ...one element in the overscroll element of another element. If that other element is at the end of its scroll, you can keep scrolling to reveal.
<masonf> ...binding through button or <a> element
<masonf> ...via idref that says this content goes in my overscroll.
<masonf> ...use link or button so that there's another way to do it always.
<masonf> ...comes with events also, this overscroll area has been activated. E.g. swipe to dismiss, do something when that happens.
<masonf> q+
<masonf> ...that's roughly it. I won't talk about implementation, but roughly nested scrollers that are automatically created by this, with snap points appropriately.
<scott> q+
<masonf> ...at parsing time, how do you establish this, e.g. you can parse the button first, but we can figure that out.
<bkardell> q+
<gregwhitworth> masonf: only question was - about the new events
<lwarlow> btw overscroll-target as an attribute name isn't fitting with html. It should be all one word.
<gregwhitworth> masonf: I can see the convenience there but since you're attaching to button or link do you need extra events?
<gregwhitworth> vmpstr: we considered that
<gregwhitworth> vmpstr: if you access this via a scroll gesture that would result in a button click
<masonf> vmpstr: we thought about that. If you access this through scroll gesture, that'll result in a button click. Don't know if that's expected.
<masonf> oh thanks greg
<gregwhitworth> vmpstr: when it animates into view it starts it and at the end the event is fired
<gregwhitworth> vmpstr: where as when a button is clicked it's immediately fired
<gregwhitworth> vmpstr: so they are then out of sync
<gregwhitworth> masonf: it feels like the more you make it the same looks identical to clicking a button the less issues you'll have
<gregwhitworth> masonf: my concern is that the dev only hooks up to one event and then it causes the issues
<gregwhitworth> vmpstr: we have proposed that the button would invoke events as well
<gregwhitworth> vmpstr: an example is that a list that has a trash icon it would have it animate away on click but it wouldn't swipe away
<gregwhitworth> ack masonf
<bkardell> q-
<gregwhitworth> ack scott
<masonf> scott: interesting proposal. Reading through it (quickly) I get the point, my initial take is that I would have expected the reverse.
<flackr> You also get nice compat with a click event in that content that doesn't support the feature still has a clickable button that does the action
<masonf> ...now the button has the scroll target and scroll host on it. I'd have thought the menu was the thing that has the overscroll on it.
<bkardell> `<overscroll>` ?
<bkardell> q+
<lwarlow> q+
<masonf> ...I saw that looking at navigation menu - in that case, that'd be a modal dialog. Dragging to the right causes that to be a modal, obscure by backdrop, etc.
<bkardell> q-
<masonf> ...if I was clicking on that as a button, that'd be a modal dialog. Is that something you can do with CSS somehow? Without dialog/inert semantics?
<masonf> ...are we firing a click on the button as that happens? If they do it slowly, it'll transition, so it'll be semi-inert. Does that fire a show modal function somewhere?
<masonf> ...how does that square with it being a command in a menu. Swipe right to get additional commands. That doesn't make anything inert - you want both.
<masonf> ...put it on the element that should be used instead, and use swipe as a way to invoke it. Vs. attaching to the button, and hoping semantics are correct.
<masonf> vmpstr: I need to digest everything you said. But specifically - we have considered making this relationship established by the menu and host element.
<masonf> ...one issue is that there is no way to enforce that this menu is also accessible by a user that isn't using swipe gestures. That's why we went with the button/link approach.
<masonf> ...to enforce that.
<gregwhitworth> q?
<keithamus> q+
<masonf> scott: it's not that I don't agree with that. There needs to be an association. We already have `command` and `commandfor`. Define the element we want to be scrolled out via those attributes. It's on the button now, but not the element that can be scrolled in.
<gregwhitworth> ack lwarlow
<masonf> (scott, check my minutes, please.)
<masonf> lwarlow: similar thoughts to scott. On the dialog - this is something you want completely separately to this feature. Want modal menus. Drawer is an example.
<bkardell> +1 - this is why I kept popping into the queue and out
<masonf> ...two ways. Make it a dialog. Or make it close when focus leaves. Both of those keep you from being focused on something that isn't visible.
<masonf> ...is that problem part of menu maybe?
<masonf> ...I do agree that it's odd that this button opens a menu element, but doesn't use command and commandfor. Those are used for menus already. Seems like command/commandfor attaches the button to the menu. And then another thing that says "I'm also triggered by overscroll".
<masonf> ...yes it's good that we keep this from inventing scroll-only actions. But is button the right thing? Maybe instead you make a completely different pattern or something. People might hide the button.
<masonf> vmpstr: point well taken about command/commandfor. Are you suggesting this relationship be better connected between the menu and the thing it's attached to. The menu says it's specially attached to some particular container.
<masonf> lwarlow: yeah
<masonf> vmpstr: button becomes optional for this pattern then.
<masonf> lwarlow: maybe enforce that there's a button?
<masonf> ...menu should be saying "here is my host" and that links it. Then force the button some other way. But attributes don't all belong on the button.
<masonf> ...this should be command/commandfor, because you might want to control the button behavior. E.g. toggle. Just show. Something else.
<masonf> ...for menus that are openable, you want it to be ... maybe that doesn't apply. Maybe openable and opens inline rather than popover. That's controllable via command.
<flackr> qq+
<masonf> vmpstr: I'm cautiously ok with that direction but want to confirm that this likely makes it easier to build something non-accessible.
<scott> q+
<masonf> lwarlow: yes, but it's unlikely to create accidentally. Developers creating a menu that they want to open. They'll have a button to open that menu, desktop or menu. Then they want to add swipe gesture. They won't start with overscroll, and then figure out they can't do this on desktop.
<nmn> q+
<masonf> ...will defer to scott on whether that's terrible.
<gregwhitworth> ack flackr
<Zakim> flackr, you wanted to react to lwarlow
<masonf> flackr: clarifying question: command could determine whether it's modal. But what will swipe do? You haven't gone through a command invoker, modality comes from menu itself, not command.
<masonf> lwarlow: you're right the swipe would need to know. Good point.
<masonf> ...still want to have a button that toggles, whereas swipe would be show/hide kind of thing.
<masonf> ...with this pattern, is the button allowed to be within the overscroll area?
<masonf> flackr: nothing prevents that
<masonf> ...same as show dialog within a dialog
<masonf> lwarlow: ok, makes sense. One other thing: no hyphens in attributes, unless you're aria.
<gregwhitworth> ack keithamus
<masonf> keithamus: I'd like to advocate for the buttons. I raised it in CSS. I agree with Scott and Luke that menu is the main focus.
<masonf> ...amount of idrefs on the button itself, which is developer-confusing. Doesn't matter for semantics. Developers don't love idrefs.
<masonf> ...overscroll can jut be a boolean attr on the menu container?
<lwarlow> Also these should be idrefs not selectors.
<masonf> s/jut/just
<masonf> ...menu declares that it has overscrollable stuff, then I don't know what to do from there. Are those relationships in CSS? And then what's the attribute?
<masonf> ...this isn't just mobile vs. desktop. You might have sliding menus on both, e.g. in narrow viewports. But it's a mouse vs. touch question.
<masonf> ...ipads, you might use both.
<masonf> ...good to keep in mind. I don't agree with Luke that you're going to add a button anyway. You almost always want to have a button, and we should encourage that. If they try to hide it, we can't force them, but we can encourage.
<masonf> ...you almost always want this to be modal. If we use command/commandfor on button, you can control that behavior. If browser knows about the relationship, then command=showmodal could be read and mapped over to the scroll gesture also.
<masonf> ...doesn't have to be done via click, just read the content attribute and do the right thing.
<lwarlow> q+
<gregwhitworth> ack scott
<lwarlow> Could just do overscrollcommand="" and overflowscrollcommandfor="" ;)
<masonf> scott: nice comments. my point was just that the overscroll thing can be identified as such. Someone might use dialog, or they might use some other thing.
<keithamus> q+
<nmn> or command="overscroll-open" commandFor="#foo"?
<masonf> ...if this is positioned, easiest thing might be to just have the attribute cause display:none by default. So it can be offscreen automatically, to avoid people having to do stuff manually.
<masonf> ...triggering element - could be a button, or a menuitem, could be a hyperlink with a target selector.
<masonf> ...there needs to be a mechanism to activate via keyboard, and not require drag. But doesn't have to be a button.
<masonf> nmn: couple things. I don't have strong opinions about button and api. But based on Luke/Keith: first thing I ever built was an overscroll menu without a button. We need to encourage a button.
<masonf> ...instincts don't always lead to the right place.
<masonf> ...I'm uneasy talking about touchscreen vs. mouse. Overscroll isn't specific to touchscreen. Touchpad is a thing.
<masonf> ...that part is important. Last concern: we're overindexing on out of screen menu use case. There are other things like pull to refresh, etc. Not super common because they're hard.
<masonf> ...I've seen that for a little easter egg or hidden extra info that isn't interactive.
<masonf> ack nmn
<masonf> lwarlow: we need to be careful not to use "gesture" because standards.
<masonf> ...good point that isn't really touch. It's overscroll, so linked to scroll, and so that's a good point.
<masonf> ...might not be modal - that's a good point. Often navigation menus - side bar can be a drawer that overlaps, but also they can just expand. Use this for that?
<masonf> ...perhaps not the right model for that?
<masonf> ...even if we want to encourage the trigger, we could still do that without attributes being on the trigger. The container could say "my overscroll target is this menu, and my overscroll trigger is this button/link thing"
<masonf> ...and then the button still uses command/commandfor.
<masonf> ...I think that allows you to read the command from the button.
<masonf> ...just set an overscroll command. Attributes are currently selectors, but they should be idrefs. We shouldn't do something special.
<masonf> ...idref ergonomics is a separate conversation.
<masonf> ...but go with idrefs.
<masonf> ...would be interesting to see more use cases.
<masonf> ...maybe think more about examples that are separate from the existing ones, to make sure we've thought of corner cases.
<masonf> ack lwarlow
<masonf> ack keith
<masonf> keithamus: agree with examples comment. Google maps example with bottom sheet. Markup could be completely different, e.g. customizable select.
<masonf> ...what is the diversity of markup here - maybe that helps to find the right design.
<flackr> q+
<masonf> vmpstr: just to be clear, we're talking about establishing semantic relationship of two elements, the container and some content in the overscroll area. Actual positioning (left vs. right, or peek from bottom) isn't something we've discussed.
<masonf> ...largely because CSS is the way to do the positioning.
<masonf> ...UA can determine how much overscroll to scroll, based on content. So bottom sheet would be very similar to side menu, except that it peeks.
<masonf> ack flackr
<lwarlow> q+
<masonf> flackr: using command for the swipe gesture. If there's no association from menu to button, that feels weird and magical. More than one button with different behaviors for the same menu.
<masonf> ...activation mechanism is a click on the button. Then the menu refers to the button it wants to click. That ties things together. Swipe this, activate that button.
<masonf> ...that's a bit cleaner than discovering that there's a button that happens to refer.
<masonf> ack lwarlow
<masonf> lwarlow: menu in that case is the overscroll container. It will have overscrolltrigger, idref'd to the button/link/etc.
<masonf> ...for that to work, for the bottom sheet that doesn't make sense because you don't need a button.
<masonf> vmpstr: you do if you're not using scroll/swipe gestures.
<masonf> flackr: the button is within the bottom sheet itself. Click it to expand the bottom sheet.
<masonf> lwarlow: why do we need a non-scrolling way, if it's part of the scroll container. You can do that with keyboard already.
<masonf> vmpstr: not in the scroll container, it's in the overscroll area. Element doesn't have to be a scroller, and we're not planning to make keyboard scroll (arrow keys) able to access these area.
<masonf> s/area/areas
<masonf> keithamus: you might not have a keyboard, and you might not be able to perform scroll gestures. You need a keyboard equivalent.
<masonf> ...it might be too difficult to swipe, but tapping is ok. Or you could be using a stylus, where tapping is ok, but swiping isn't.
<masonf> lwarlow: touch input is the modality but you can't do swipe. Ok.
<masonf> ...explainer says this is a scroll into view of the overscroll area.
<masonf> ...for menus, command on button approach doesn't have that. You can show the menu as a popover, or openable. Could use openable and still have peek behavior.
<masonf> ...maybe that's enough. With scroll into view design, how would that work with the button? We might need commands that can also do scroll into view?
<masonf> ...anchor targets can do that. Possibly it'd be a link that targets it, to get scroll into view behavior.
<masonf> ...or add a command for buttons.
<masonf> q?
<masonf> keithamus: do you see this having overlap with view transitions?
<masonf> ...snapchat - you're performing destructive navigations almost. Is that a good use case for this? Or view transitions? But then we need gestures there.
<masonf> vmpstr: two flavors of VT. You're talking about cross-document or same-document?
<masonf> keithamus: implementation detail, but let's say cross document.
<masonf> vmpstr: we haven't considered doing navigations as a result of these gestures. David has thought about that.
<lwarlow> q+
<masonf> ...I think this API ends with just events with the right timing, so you can do what you want to do.
<masonf> ...interesting to consider connections to other things like snap-to-activate but haven't thought it through.
<masonf> flackr: hypothetically, on start of overscroll, start VT, then tie VT to scroll.
<masonf> ...without that, there are destructive things like swipe to delete.
<masonf> ack lwarlow
<masonf> lwarlow: how does scroll triggered animations integrate?
<masonf> ...it's overscroll rather than a scroll container. Would be nice if this was a special kind of scroll container, to allow connect to scroll snap, animations, etc.
<nmn> q+
<masonf> ...not using gesture word is better, use scroll instead.
<masonf> vmpstr: we are planning to support exactly that.
<masonf> ...this is an overscroll area, but it's really just a scroller.
<masonf> ack nmn
<masonf> nmn: small note: I've been trying to implement these behaviors with scroll snap, etc., and two more things needed:
<masonf> ...1. lock a parent scroller when an overscroll element is visible. For side menu, disable body scroll while side menu is open.
<lwarlow> q+
<masonf> ...2. on iOS specifically, I was testing this pattern, and it works on desktop. But iOS is gets wonky - needs scroll locking to be defined somehow.
<masonf> ...when you add body scroll in both directions, browsers treat that like same as google maps where you can scroll diagonally. Want to define explicitly one or the other.
<masonf> vmpstr: overscroll behavior that can lock scroll port to a container - exists in CSS? {flackr nods}
<masonf> ...I agree with that. There are a few things we need to polish to get this right. Best way is to cautiously proceed with implementing it to see how it feels.
<masonf> ack lwarlow
<masonf> q+ lwarlow
<masonf> vmpstr: need input on the next thing we should try
<masonf> ack lwarlow
<masonf> lwarlow: locking of parent scroller thing - that comes up a lot.
<masonf> ...modal dialogs, for example.
<masonf> ...can do it with has but not with shadow roots. That's definitely a need.
<masonf> ...that doesn't work on iOS Safari, body scroll locking.
<masonf> ...scroll on iOS isn't fun.
<masonf> ...next steps: rough explainer to land in OpenUI perhaps?
<masonf> ...alternative is prototype and come back when ready and discuss again
<masonf> keithamus: do you feel like you've gotten what you want from this session?
<masonf> ...or if not, how can we be better.
<masonf> vmpstr: this was great. Main thing: ID people who hate this and talk them out of that position.
<masonf> ...relationships between buttons and attributes is all easy to change, so that's great feedback.
<masonf> ...difficult implementation is getting the model correct, and I think I have the support I need to proceed with that.
<masonf> ...I'll talk with Mason about how to do explainer in OpenUI. In parallel with prototyping.
<masonf> scott: I do appreciate you working on this problem.
<masonf> ...I don't always think there needs to be a trigger, but defaulting to that is a great starting point. Make people work to remove it.
<masonf> Proposed resolution: land an explainer in OpenUI
<lwarlow> +1
<masonf> RESOLVED: land an explainer in OpenUI