open-ui
open-ui copied to clipboard
openui
[command invokers] scroll command
I think that we should be able to set up a scroll command for buttons similar to the implicit scroll that you get with the ::scroll-button pseudo-elements: https://drafts.csswg.org/css-overflow-5/#scroll-buttons
My thinking is that this would be something like the following:
<div id=scroller>
</div>
<button command="scroll(down)" commandfor="scroller">Show more</button>
I'm open to bikeshedding on whether a functional syntax makes sense, if it needs changing or if we should break this out into a series of scroll-* commands, though note that we have many directions and we may want to introduce / support distances as well (e.g. scroll to top).
Also, if you leave out the commandfor attribute, I think reasonable behavior is to scroll the nearest ancestor scroll container to the button.
We don't have implicit commandfor yet and I don't think we should block this scroll command on that functionality but it's definitely worth a discussion.
The Open UI Community Group just discussed [invokers] scroll command.
The full IRC log of that discussion
<jarhar> flackr: with the overflow 5 spec we have a way to make buttons that scroll scrolling containers<jarhar> flackr: it was always the plan to make authors do this with their own buttons
<jarhar> flackr: we should have a command invoker for scrolling
<jarhar> flackr: theres a few details or complications to scrolling. theres a direction, maybe a magnitude like a page
<jarhar> flackr: i dont know if invokers have attributes
<masonf> q+
<keithamus> q+
<jarhar> flackr: if you dont specify a target, then the nearest ancestor scrolling would be scrolled. a scroll button within a scroller would scroll its containing scroller
<jarhar> flackr: can create these without any script
<jarhar> flackr: at least the direction into the command
<bkardell> q+
<jarhar> flackr: whether it should have a bunch of commands included or functional syntax
<sorvell> q+
<jarhar> masonf: i like the idea. i generally like the idea of adding more commands
<jarhar> masonf: luke mentioned that we dont have any other implicit ones that walk up the tree and find their commandfor. i do like that idea and it applies to other things like popovers or dialogs
<jarhar> masonf: that is important to note thats not a thing yet
<jarhar> masonf: the other thing that isnt there yet that is some sort of attribute that is a value for the command
<brecht_dr> q+
<jarhar> masonf: i see that there are use cases where a third value is needed, but im partial to the syntax you invented, where it scroll of something with the extra bit you need
<masonf> ack mason
<keithamus> ack masonf
<jarhar> keithamus: this would be a new precedent if we have an implicit commandfor
<jarhar> keithamus: theres also precedent for using the new attribute when you close a dialog, it passes the value of the button to the close command on the dialog
<scott> q+
<jarhar> keithamus: we do have precedent for the value attribute being used
<Penny> q+
<jarhar> keithamus: i think it fits well there and i dont see it fitting well here, its not like a keyboard
<jarhar> keithamus: i would be against using the syntax with parens, it looks like code
<jarhar> keithamus: i also worry that if we expand all of these as you suggested, scroll dash something, then with css vernaculars with logical properties, were going to have 9 different commands to add
<jarhar> keithamus: i do think its a really interesting idea
<jarhar> flackr: scroll to top is a common need, i could see there being additional arguments as well
<jarhar> flackr: do we not have implicit targets for form reset? or is that not a thing?
<jarhar> masonf: the only commands that have landed are popover and dialog
<jarhar> keithamus: you can specify a form attribute on the button
<jarhar> keithamus: we could look at the same pattern for commandfor. it just doesnt have existing precedent yet
<jarhar> masonf: there are definitely use cases, but we haven't landed them in specs yet. a close button on dialog is an example
<keithamus> q?
<keithamus> ack keithamus
<keithamus> ack bkardell
<jarhar> bkardell: i wonder if it might makes sense for commands to do the equivalent of send keys, because when you thinik about it, its do the equivalent of pushing the arrow down key on that element
<jarhar> bkardell: maybe if we had something like that, we could do a lot that also encouraged good keyboard behavior
<jarhar> bkardell: vague thought, but something that popped into my head
<jarhar> masonf: a way to set up a command relationship where pressing a key on the thing with command forwards the key?
<jarhar> flackr: simulates that key. so you click the button, and its going to send the pageup key to the scroller
<jarhar> bkardell: down is down or right, up is up or left
<jarhar> flackr: you can scroll in 2 directions
<jarhar> sorvell: almost the same as brian, i had almost the same thought but different
<jarhar> sorvell: in terms of behavior, i agree, but i think that some of these questions, some of the behavior is described in css. theres scroll behavior, should it go to this parent, that all is equivalent. if you pressed the key, it would do that thing
<jarhar> sorvell: behavior wise, they should function the same. conceptually, the command invoker system, actually being able to simulate a key scares me. i dont think thats good
<jarhar> sorvell: the user didnt do that
<jarhar> sorvell: instead, the concept is scroll up. the up arrow invokes scroll up, and theres a command that does the same thing
<bkardell> yes
<jarhar> sorvell: that leaves the spec issue to be resolved
<jarhar> flackr: i dont think you actually want the scroll to propagate for these cases, good reason not to do the command thing
<jarhar> flackr: if you have a button thats meant to control a particular scroller, it shouldnt propagate to other scrollers
<jarhar> flackr: different from arrow keys
<jarhar> flackr: i dont know of the use case where you would want it to propagate, but there are use cases where you dont want it ot
<jarhar> masonf: the carousel is one of those cases. you dont want it to scroll the page, just the carousel
<keithamus> q?
<keithamus> ack sorvell
<keithamus> ack brecht_dr
<jarhar> brecht_dr: i have two thoguhts on this. one of this is the direction. i want to keep the logic not based on an actual direction like up right left down. ltr styles, that would be pure horror
<jarhar> brecht_dr: the other thing i was thinking about, where brians idea would help, is what happens when you press hold something? if you have carousels in css, youre using mandatory scrolling. it snaps. but what if you dont have that and you press hold and it keeps scrolling? is that something that can work with invokers? it repeats the action?
<jarhar> brecht_dr: whats the ? of that action?
<jarhar> flackr: there was never a question of it not supporting logical directions, those are part of the scroll buttons spec. maybe we should not bother with physical directions
<jarhar> flackr: maybe its worth thinking about repeating actions for ones that make sense to repeat
<jarhar> flackr: i think theres a case where you hold a key on the keyboard it might repeatedly invoke the action. we dont have these for mousedown or other things like that
<jarhar> brecht_dr: if you hold your arrow key, your container will keep scrolling. probably want to have the same thing with a mouse click anywhere on the button
<jarhar> flackr: yeah you probably get this for free with the keyboard intreaction, and we could replicate this for other input modalities and we would have to figure out if this makes sense
<keithamus> ack scott
<jarhar> scott: i want to give a giant plus one to the idea of having actual html elements be the thing that control this stuff
<bkardell> +1
<jarhar> scott: thank you youve made my dreams come true even though my nightmare is still happening
<jarhar> scott: i want to throw a wrench into the passing keyboard thing, i dont know if that makes sense here
<jarhar> scott: were not kind of scrolling, were going to distinct part of the scroller. pressing the down arrow key to scroll, it only scrolls down a tiny bit
<jarhar> scott: youre either doing that or space or page down or shift and space
<jarhar> scott: the whole bidirectional thing where that is a thing that happens but does it happen in this context? probably not
<jarhar> scott: i would be hesitatnt to having any kind of keyboard arrow key mapping for this
<flackr> +1
<jarhar> scott: youre trying to move forward and backward
<bkardell> sure... 12 seconds thought :)
<jarhar> scott: outside of that, i dont have any intelligent thoughts, other than yes make these html elements
<jarhar> Penny: is there an option in addition to jumping to an element to a direction, distance plus unit parameter, useful for maps, gaming, drawing, move a canvas around thats inside a scroller
<jarhar> flackr: id love to continue this discussion next time
The Open UI Community Group just discussed [invokers] scroll command.
The full IRC log of that discussion
<frehner> flackr: I think we should have invoker commands for scrolling in a direction<gregwhitworth> q+
<frehner> flackr: I have a rough proposal in the issue, but doesn't go into specifics. A command for each direction, for distances - page versus to top.
<lwarlow> q+
<frehner> flackr: One potential argument is step up and step down. This could benefit from a common syntax
<masonf> q+
<frehner> gregwhitworth: No strong opposition. I like page up / down. I don't know if it would be up / down because of CSSWG opinions. Could be UA defined.
<frehner> gregwhitworth: Snap points - I think they should magically work. Should page down go past snap points?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack lwarlow
<frehner> flackr: There is already interaction. Scrolling skips snapping points already, unless you set it explicitly
<frehner> lwarlow: We already have arguments in command invokers, e.g. close on a dialog. Maybe the value attr on the button provides that.
<frehner> lwarlow: That said, ideally these commands are simple. Regarding step up/down they match functions that already exist.
<frehner> lwarlow: It does take step increment. That's probably the way to do it. I can't remember how step attribute does it.
<keithamus> q+
<frehner> lwarlow: Scrolling wise, it's possible you want to do stuff like "scroll into view".
<frehner> lwarlow: There is a JS function for this. Maybe you want that instead.
<keithamus> s/JS function for this/JS function for this (scrollIntoView)/
<lwarlow> https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView
<frehner> lwarlow: Depends on use case. Related to carousels. "Scroll into view" has been used before
<frehner> flackr: Scroll into view is a different feature. We could add an invoker API for this, but not appropriate for "see next item".
<gregwhitworth> ack masonf
<frehner> flackr: You can't change the ID, defeats the value of invokers
<brecht_dr> q+
<frehner> masonf: Video and audio could also be used here. Seems like for the syntax, maybe 1) microsyntax, 2) a separate attribute, and 3) constructing new names for everything
<frehner> masonf: I would prefer another attribute approach. It's already a thing, doesn't clutter up the namespace
<flackr> +1 to using value attribute
<lwarlow> q+
<frehner> masonf: We don't need that very often. Scroll up by a page by itself is mostly useful by itself.
<frehner> masonf: ideally we keep it simple and add another attribute
<frehner> flackr: I like the idea of putting directions in the command name. I hope there aren't a ton of different distances needed. But it would be good to hear usecases
<frehner> flackr: Would be nice to see the three different options written up to see and compare
<gregwhitworth> ack keithamus
<frehner> keithamus: Enumerating the usecases would be nice. Would be nice to understand the problem space better to drive to a solution.
<frehner> keithamus: I don't like any of the 3 options. They overload the space; it feels to be too much for developers to keep in their heads
<frehner> keithamus: I'm also worried about "writing incantations". I want to be able to intuit it instead of having to look it up in a giant reference
<frehner> keithamus: Another direction: scroll has previous and next. Is that a minimum set of things we could put in invokers
<frehner> keithamus: Trying to pivot all the way into HTML feels worse than maybe using some HTML and CSS together. Could depend on the particulars of the CSS of the element
<frehner> keithamus: The scroll behavior for next for the container could read the style rule for the other thing and do the changes
<scott> q+
<frehner> keithamus: If we put too much into HTML, especially dimensions, that will result in people using JS to manipulate the attributes which kind of defeats the purpose of them
<masonf> q+
<frehner> keithamus: Dimensions should be left out of HTML
<gregwhitworth> ack brecht_dr
<frehner> brecht_dr: I would love to keep invokers in simplicity.
<frehner> brecht_dr: Carousels: is there a disabled state at the end? Scroll markers? [no]. Ok, purely for direction.
<gregwhitworth> ack lwarlow
<frehner> flackr: Agreed on disabled state, automatic would be nice.
<frehner> lwarlow: Share same concerns as Keith. It's not necessarily wrong to have a lot of commands, but I do agree for a given space it should be intuitive to know relevant commands.
<frehner> lwarlow: Scrolling "by page" vs "an amount": it's not clear to me that distinction needs to exist.
<frehner> lwarlow: if I have scroll snapping, then it does what I want.
<frehner> lwarlow: scrolling down a whole page, I don't think is that useful.
<frehner> lwarlow: We already have fragment links. Common to use that already. We probably don't need to recreate that. We already have stuff in CSS for that, too.
<keithamus> q+
<frehner> lwarlow: scroll previous/next seems unnecessary. Not clear on the value the attribute provides
<frehner> lwarlow: A list of use-cases where CSS can't handle it would provide more understanding for us.
<frehner> lwarlow: I think some scroll commands pointing at a scroll container could do it. Some types of queries could be used to tell if you're at the end
<frehner> flackr: That's explicitly an anti-pattern
<frehner> lwarlow: You could do automatic wiring because we have invokers. Not clear if that's always desirable.
<brecht_dr> q+
<frehner> lwarlow: Having a button that's disabled and doesn't do anything is... ok? But maybe it should be focusable.
<frehner> lwarlow: TLDR: I don't think we need scroll commands.
<gregwhitworth> ack scott
<lwarlow> I think previous and next doesn't neccesarily work if you want scrolling in 4 directions which I think seems reasonable to allow? Hence allowing directions seems fine too?
<frehner> scott: My thoughts: in between Luke and Keith. The simplicity of having "previous" and "next" as the commands the browser knows to scroll to the next snap point, or scroll the whole panel of content, or setup where multiple panels are shown but the middle is focused, but if the browser could do all that it would be great.
<frehner> scott: I don't understand up/down/left/right, what does that mean? It's a scroll forward / back, which is either horizontally or vertically depending on the setup
<frehner> scott: I see the need of scrolling to specific items. Could be inferred that would be great, but if we had an ID as a target would be nice. But also, are we overlapping with scroll markers already allows using hyperlinks and fragments?
<frehner> scott: we already have hyperlinks. If we use "next" then the browser can just automatically do this work. But hyperlinks have an ID they could scroll to
<frehner> scott: If someone is trying to do something beyond that, then aria roles can be used as well
<gregwhitworth> ack masonf
<frehner> masonf: I generally agree. Keeping it simple is a good start. Let's list use-cases and corner cases. What if "next" / "previous" points to a 2D scroller?
<frehner> masonf: The one bit that scares me is the auto-disabling behavior. We have a "show popover" command; should that be disabled if it's already shown?
<frehner> masonf: This would be the first thing that changes behavior depending on the target
<frehner> scott: I remember we talked about this with popover. We purposely did not get into the realm of automatic disabling.
<frehner> scott: If something is automatically disabled, focus is lost. And that's a bad experience
<gregwhitworth> q?
<frehner> scott: because CSS has a disabled state, we hoped we could expose that as aria disabled but not full-on disabled. Hopefully a screen reader would still get that experience.
<frehner> scott: Because there was styling associated with the disabled class. But with popover we never got that far and added a pseudo thing for that. But also popover, no change in the expanded state
<frehner> scott: For this, if there is going to be actual disabled styling state, it needs to be programatically exposed, but it doesn't need to be the actual disabled attribute. Just needs to be clear to the user it's disabled
<gregwhitworth> ack keithamus
<lwarlow> +1 to what Scott said
<frehner> keithamus: I wonder if more of that could be pushed to CSS. If you can express that your carousel is bounded, maybe it's a property away
<frehner> keithamus: value attribute is just kind of raw data, it is not reasoned about. The value attribute has semantic relevance.
<masonf> that's a very good point
<gregwhitworth> ack brecht_dr
<brecht_dr> https://codepen.io/utilitybend/pen/WbeqKNv
<keithamus> s/value attribute has semantic relevance/value attribute has no semantic relevance/
<frehner> brecht_dr: I shared that link. I see benefit of all directions. The example is both way. Maybe diagonal too. Left/right/up/down and logical variants seems like a good first step, and let the browser handle it.
<keithamus> q+
<frehner> brecht_dr: Scroll stop always could work here too.
<frehner> brecht_dr: CSS has snapping that does so much already. Directions is the most important thing. This seems to be what makes sense for most people
<gregwhitworth> ack keithamus
<frehner> keithamus: I'm curious why CSS continues to spec both logical and non-logical properties. Directional is not enough for HTML; it depends on display.
<masonf> ...more than 8 values in some cases: https://developer.mozilla.org/en-US/docs/Web/CSS/position-area#formal_syntax
<lwarlow> q+
<frehner> keithamus: You might change direction based on screen space, not just on values.
<frehner> keithamus: Another form of orientation system for 2 or 1 dimension
<frehner> keithamus: Maybe CSS could do this? One command, such as "scroll", and then use CSS to choose which direction is scrolled?
<gregwhitworth> q?
<sorvell> q+
<frehner> flackr: That feels weird. I would rather have the direction
<frehner> masonf: direction feels semantic
<gregwhitworth> ack lwarlow
<frehner> lwarlow: If people want to do responsive design and change the direction, use media queries to have multiple buttons. It's less magical there.
<frehner> lwarlow: It can make sense to have logical and "illogical" values.
<flackr> sometimes just the labels for understandability
<keithamus> q+
<frehner> lwarlow: I don't think previous/next is as easy as it seems. The browser has to do magic here. You could end up in weird behavior
<frehner> lwarlow: previous/next makes sense, but the directions also make sense.
<frehner> lwarlow: We could even not do logical to start with. Or only do logical
<frehner> lwarlow: but next/previous being "simple" doesn't seem necessarily true. Your carousel could be tied to the contents of it.
<frehner> lwarlow: For no other reason than CSS has it, so HTML should probably have it too. Unless it's not justifyable, then it should be removed
<frehner> lwarlow: It shouldn't be its own syntax
<gregwhitworth> Zakim, close queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<frehner> lwarlow: I think this sounds good
<gregwhitworth> ack sorvell
<frehner> sorvell: Two more use cases when you want to do this programatically. 1) jumping to a specific item
<frehner> flackr: we have anchor links for that
<frehner> sorvell: You can do that with an invoker?
<frehner> flackr: we may not have one, could maybe make one?
<frehner> sorvell: 2) A wrapping overflow; going from end to beginning.
<gregwhitworth> ack keithamus
<frehner> flackr: some new value for that, yes.
<frehner> keithamus: another way to think about this, in addition to two directions, maybe it can be an ident that can be accessed in CSS
<frehner> keithamus: it could avoid all these different commands, and could allow devs to define what they want
<frehner> gregwhitworth: Can we resolve on this or take it back?
<masonf> q+
<frehner> flackr: Maybe don't worry about scroll to top.
<frehner> gregwhitworth: I liked seeing the use cases and
<frehner> masonf: Take all the feedback and put it back into the explainer, and we could read it all again and talk next week (or whenever).
<frehner> masonf: a PR against the explainer for invoker commands makes sense
<gregwhitworth> Zakim, end meeting
To summarize the recent discussions, I think the overall direction we're leaning is to define different commands for the directions (4 physical 4 logical), and not to have different distances at the current time. I can put together a PR and some examples of use cases where developers are doing these sorts of things to help further the discussion.
Hey just to ping on this to see how things are going. scroll-target-group to do the table of contents scenario via HTML + sprinkling of CSS feels like a good first step to righting some of the "wrongs" of CSS carousel, and these command buttons (or some similar HTML oriented design) feels like a good next step.
The Open UI Community Group just discussed [command invokers] scroll command, and agreed to the following:
-
RESOLVED: page as common command name, 4 physical and logical directions, no functional microsyntax.
The full IRC log of that discussion
<keithamus> scribe+<keithamus> masonf: first issue is command invokers scroll command. flackr to present?
<keithamus> lwarlow: I added this to the agenda, but some time has passes so I wanted to keep the ball rolling on it
<keithamus> masonf: can one of you remind us of the proposal
<keithamus> masonf: there was talk of a functional microsyntax but that's not the direction?
<keithamus> flackr: right
<bkardell> q+
<keithamus> flackr: we should bikeshed the names of the values but they are the 4 physical & 4 logical directions.
<keithamus> bkardell: I wanted to clarify, it's paging right? One whole scroll port
<lwarlow> q+
<keithamus> flackr: yes
<keithamus> bkardell: maybe page is better
<keithamus> flackr: we can start with page.
<keithamus> masonf: Like page down?
<keithamus> flackr: yes those make sense. page-block-end maybe less so.
<bkardell> exit, stage left, chased by a bear
<keithamus> masonf: it's descriptive.
<masonf> ack bkardell
<masonf> ack lwarlow
<keithamus> lwarlow: this works with scroll-snap and scroll containers. I assume - how do things like page up page down buttons work with scroll snap? The container?
<keithamus> flackr: It's complicated. Well defined, this would mimic that. You scroll by about a page and find a snap point near that destination
<keithamus> flackr: the reason you dont want to go to the next snap item is you might have a set of small snap items, and so moving a page might trap you in those snap items
<keithamus> masonf: the behaviour of the page up and page down keys is expressed in the spec?
<keithamus> flackr: it's hand wavey but we have tests and such. This would hook into the same mechanism.
<keithamus> masonf: Are there other questions? Naming aside. Other questions to be answered?
<keithamus> lwarlow: I guess - is it ready to just propose to whatwg?
<keithamus> lwarlow: bikeshedding doesn't need to happen here.
<keithamus> flackr: i guess so. The target needs to be the scroll container, there's no magic "find the nearest scroll container".
<keithamus> lwarlow: there is an issue in whatwg to handle that, it could piggy back that if there was anything we could come up with
<keithamus> masonf: auto targeting based on ancestor chain?
<keithamus> lwarlow: yeah. It's up for discussion what shape it would take. But for something like this it would probably be the nearest scroll ancestor.
<keithamus> masonf: that's separate and more general anyway
<keithamus> masonf: one plan is to take it to whatwg but another is to prototype this, right?
<masonf> q?
<keithamus> flackr: yeah probably not too hard to prototype, I assume adding commands isn't difficult
<masonf> keithamus: the spec has a handle invoke step, which is awkward, but implementations are easy
<keithamus> lwarlow: not too difficult
<keithamus> flackr: maybe that's the plan, write a rough explainer, prototype, bring to wg.
<keithamus> masonf: sounds like it has 2 champions, lwarlow and flackr? Presumably one of you will do this?
<keithamus> lwarlow: I am fine to work on the html spec parts. Implementation wise I can help with the command stuff, but not the scrolling bits
<keithamus> flackr: I know about those bits so I can handle those. I'll reach out
<keithamus> PROPOSED RESOLUTION: page as common command name, 4 physical and logical directions, no functional microsyntax.
<bkardell> +1
<lwarlow> +1
<keithamus> RESOLVED: page as common command name, 4 physical and logical directions, no functional microsyntax.
With the scroll command (or the other command invokers) do we have the ability to have an implied disabled state when the command is not feasible. E.g. there is no more scroll in that direction, or perhaps disabling the hide-popover button when the popover isn't open?
Reading https://open-ui.org/components/invokers.explainer/#accessibility it sounds like maybe we could do this, has this been discussed? Or should we discuss it here?
The button may also use the commandfor referenced element to gather other details (for example the state of the element) to reflect that state on the button.
We can absolutely implicitly set an aria-disabled (I'm assuming you probably still want it to be focusable?) the same way we set aria-expanded and aria-details.
We can absolutely implicitly set an aria-disabled (I'm assuming you probably still want it to be focusable?)
I don't think you do want it to be tab focusable. Every library I've seen disables the button removing it from focus order if there is no cycling back to the other end.
But if I'm currently on the button and it suddenly becomes disabled after activation that's pretty bad right?
Either way we absolutely can "do the right thing" here. That's one of the benefits of built-in commands.
But if I'm currently on the button and it suddenly becomes disabled after activation that's pretty bad right?
I think you want tab ordered navigation to proceed from the button still. But I do think you want to disable it, be able to style it as a :disabled button, etc. We could consider the button to still be the sequential focus navigation starting point to make this work, https://html.spec.whatwg.org/#sequential-focus-navigation-starting-point
Either way we absolutely can "do the right thing" here. That's one of the benefits of built-in commands.
Great! As long as we can do the right thing we can work out the details of what the right thing to do is.
This is actually the biggest issue have with DOM buttons for controlling scrolls in general. There’s not only the disabled state; Meaning a state where the command might be in general possible, but currently not available. For example because it reached the end.
There’s also an hypothetical impossible state. Where the command isn’t possible at all. For example if you have a scroll-next command in the block direction but the target container does only overflow in the inline direction. Or even has no overflow at all. Or plainly doesn’t exist, is hidden, empty … and so on.
CSSOM View has some APIs for scrolling. Have you considered extending those?
CSSOM View has some APIs for scrolling. Have you considered extending those?
Could you give an example of what you mean by extending those?
This is aligning with the ::scroll-button pseudo-element https://www.w3.org/TR/css-overflow-5/#scroll-buttons which has identical behavior to scrolling by a page. This is actually something that's hard to do correctly with the CSSOM view api since even if you calculate the scroll distance correctly you have no way to prevent incorrect snapping which can lead to skipping content. We're working on ideas to improve the CSSOM View api in https://github.com/w3c/csswg-drafts/issues/10914