[invokers] Potential additions

[lukewarlow]

This issue is just so the meeting bot has somewhere to comment.

[sorvell]

I would love to be able to trigger commands based on change events from inputs. This would potentially enable commands that use the input's control value.

[brechtDR]

The things I think about the most:

• showPicker
• video controls: play, pause, fullscreen, mute, etc...
• audio controls
• stepUp / stepDown to add plus/minus buttons that work with a input type=number. maybe even with a range? (hinting towards enhanced range here)
• copy/paste

Maybe a bit more meta for the future:

• selectAll (to select every option in a multiselect)

Probably not:

• confetti

[css-meeting-bot]

The Open UI Community Group just discussed [invokers] Potential additions.

The full IRC log of that discussion

<jarhar> lwarlow: what followup command issues would people think be good to follow
<sorvell> q
<brecht_dr> q+
<jarhar> lwarlow: we have some ideas in the future invokers section
<sorvell> q+
<jarhar> lwarlow: think it would be good to keep the ball rolling
<jarhar> lwarlow: curious what the group thinks
<jarhar> brecht_dr: people were hyped about video commands like play start. fullscreen as well
<jarhar> brecht_dr: show picker as well
<jarhar> brecht_dr: it sort of makes sense to have show picker as one of the more next in line
<lwarlow> q+
<jarhar> brecht_dr: because of all the works thats been done on select, and showing pickers is going in the same direction
<jarhar> brecht_dr: feels like this should be the first one in some way
<keithamus> ack brecht_dr
<jarhar> brecht_dr: video one is one that would be loved
<jarhar> sorvell: this is a fantasy, but we have this thing called the output element. i could invoke a command via an input when it chagnes, and it would automatically populate the output with the inputs value
<jarhar> sorvell: not just new commands, but new ways to trigger commands
<jarhar> sorvell: like the change event from an input
<jarhar> sorvell: the thing that made this come to mind is that i did an experiment, we can do custom commands - the command event does not bubble but you can capture it. make an element that captures these custom commands and does stuff with them is possible today, and can be used to polyfill
<nmn> q+
<jarhar> sorvell: custom command where you can put random stuff in the value of hte thing sending the command, and do stuff with it on the receiver
<jarhar> sorvell: not saying all of that should be built in
<jarhar> sorvell: but maybe some use cases we we want to support there
<brecht_dr> q+
<keithamus> ack sorvell
<jarhar> keithamus: the output element is an aria live element, it has semantics and its not useless
<jarhar> lwarlow: theres value in doing that
<jarhar> lwarlow: it exists as a live region, but you have to use script for all of it
<jarhar> lwarlow: theres some attribute on output elements, like the for attribute and it seemingly does nothing
<jarhar> lwarlow: maybe theres some room there for a new attribute
<jarhar> lwarlow: for the showpicker one, thats what i had in mind. should be quite easy
<jarhar> lwarlow: one problem potentially is whether show picker is the right model
<jarhar> lwarlow: for color picker it is show
<jarhar> lwarlow: if you click the button it will close and reopen it
<sorvell> q+ quickie...
<sorvell> q+
<jarhar> ack quickie...
<keithamus> ack lwarlow
<jarhar> lwarlow: i was hoping there would be someone with a11y knowledge to say whether thats a good idea
<jarhar> lwarlow: i think it should do aria expanded but im not sure
<jarhar> nmn: i like the idea that theres more kinds of invokers, not just clicks and inputs. i dont like the idea that it does fancier things like take my data to output
<jarhar> nmn: it should be show, hide, toggle, not be fancier than that
<lwarlow> q+
<keithamus> ack nmn
<jarhar> nmn: sounds like the output element should have new features for this
<jarhar> nmn: and the invoker just tells it to update
<jarhar> brecht_dr: another one: copy and paste
<jarhar> brecht_dr: last week we talked about an option to select everything in a listbox. a select all invoker might be a handy thing
<keithamus> https://github.com/github/clipboard-copy-element
<jarhar> sorvell: riffing on what everyone is saying here, triggering a command on a change event is different from natively doing stuff
<nmn> better way to say my comment:
<nmn> invokers should update state not content
<jarhar> sorvell: i can make a custom command that does something
<lwarlow> ack brecht_dr
<jarhar> sorvell: i can then make my custom things, which isn't fully declarative but its powerful
<jarhar> sorvell: i was surprised that theres a command for showmodal for dialogs but not show
<jarhar> sorvell: we should add that
<jarhar> lwarlow: the reason that doesnt exist is because non-modal non-popover dialogs are bad and we should remove them
<jarhar> lwarlow: there are no good reasons not to have a dialog in the top layer
<jarhar> lwarlow: it should always be a modal or a popover
<nmn> q+
<jarhar> lwarlow: if you have use cases for dialogs that are popovers that arent modal
<keithamus> ack sorvell
<jarhar> lwarlow: we can add it in the future
<jarhar> lwarlow: theres use cases for an initially open dialog but thats it
<jarhar> lwarlow: they should be a popover thats initially openn
<jarhar> lwarlow: it was mentioned that command should only do ? stuff
<jarhar> lwarlow: copy to clipboard as a command is nice
<brecht_dr> q+
<jarhar> nmn: i think its fine to do actions and state updates, but not content updates
<flackr> q+
<keithamus> ack lwarlow
<lwarlow> ack lwarlow
<nmn> q-
<jarhar> nmn: i had something about a dialog thats not modal, but ill create an issue
<jarhar> brecht_dr: step up and step down for number inputs
<lwarlow> q+
<jarhar> flackr: theres a lot of use cases for things to not be globally modal, but to be modal to some inner component
<jarhar> flackr: theres always some level of modality, but maybe just prevent access to the rest of a component
<keithamus> ack flackr
<jarhar> lwarlow: yes, but theres no concept of that in the platform, so you dont get that capability built in
<jarhar> lwarlow: often times people can prevent clicking on those things but theyre not taking into account screenreaders or keyboard users
<nmn> q+
<jarhar> lwarlow: its common to see "modal" dialogs that you can tab out of
<jarhar> lwarlow: showmodal already exists but maybe we dont want to expand that
<keithamus> ack brecht_dr
<keithamus> ack lwarlow
<keithamus> ack nmn
<jarhar> nmn: the one place where a non modal dialog makes sense for toasts
<keithamus> q+
<jarhar> nmn: there are these things that look like toasts but they have buttons, and theres no good pattern that fits them
<jarhar> nmn: but everybody keeps doing them
<jarhar> nmn: non modal dialog made the most sense
<jarhar> nmn: because you still want to be able to focus out of them
<jarhar> lwarlow: why dont you use popover?
<jarhar> nmn: you can only have one
<jarhar> lwarlow: you can do manual popover
<jarhar> lwarlow: step up and step down are interesting. i have questions for a11y people for whether they should be keyboard focusable
<jarhar> lwarlow: in a number input theyre not accessible to AT
<jarhar> lwarlow: keyboards and ATs have separate ways of doing this already
<jarhar> lwarlow: them and showpicker are the interesting ones
<keithamus> Zakim, close queue
<Zakim> ok, keithamus, the speaker queue is closed
<keithamus> q?
<keithamus> ack keithamus
<brecht_dr> +1 should be checked
<keithamus> RRSAgent, please make minutes
<keithamus> Zakim, please leave
<Zakim> leaving. As of this point the attendees have been flackr, castastrophe, lwarlow, bkardell, brecht_dr, dbaron
<RRSAgent> I have made the request to generate https://www.w3.org/2026/01/15-openui-minutes.html keithamus

[lukewarlow]

stepUp / stepDown to add plus/minus buttons that work with a input type=number. maybe even with a range? (hinting towards enhanced range here)

So I'm leaning towards making these just support all "steppable" inputs. So type number, range, date,datetime-local, time,week, and month.

Now obviously it's unlikely to be used on the temporal ones, but the JS methods do work so I don't see a reason to be different here.