[Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS

[keithamus]

Following on from #3567 and #9456 where we tried to specify a way to open dialogs without JavaScript, @nt1m and @smaug---- raised concerns that the attribute was not extensible.

I've taken the feedback, and instead I'm proposing a new set of attributes that allow for opening dialogs and popovers, and also allow for extensibility for other interactions. I'll quote the summary:

Adding invokertarget and invokeraction attributes to <button> and
<input type="button"> / <input type="reset"> elements would allow
authors to assign behaviour to buttons in a more accessible and
declarative way, while reducing bugs and simplifying the amount of
JavaScript pages are required to ship for interactivity. Buttons with
invokertarget will - when clicked, touched, or enacted via keypress -
dispatch an InvokeEvent on the element referenced by invokertarget,
with some default behaviours.

In addition, adding an interesttarget attribute to
<button>, <a>, <input> elements would allow disclosure of high
fidelity tooltips in a more accessible and declaritive way. Elements
with interesttarget will - when hovered, long pressed, or focussed -
dispatch an InterestEvent on the element referenced by interesttarget,
with some default behaviours.

I'm soliciting feedback on this, and if we think this is more tenable than #9456 I'm happy to go forward with specs/implementations.

[mfreed7]

Nice proposal and explainer! I'm generally supportive of the direction this is going, and I like that you've really expanded the capabilities to include things other than <dialog> and popovers. I also see you've added an interesttarget mechanism via events to be able to handle both the "activate" and "hover" use cases, which is great.

A few small comments related to parts of the proposal:

In the style of popovertarget, this document proposes we add invokertarget, and invokeraction as available attributes to <button>, <input type="button"> and <input type="reset"> elements,

I think you'd want invokeraction on just the set of things we currently allow, which are those "buttons" you listed, but only when they don't participate in a form in some way (submitting or resetting). Mostly, I think that's what you meant, I just wanted to be clear.

as well as an interesttarget attribute to <button>, <a>, <input type="button"> and <input type="success"> elements.

Here, I think you likely can add back <input type=reset> and buttons that do participate in form submission, since you'd like to use this feature to provide context for those actions before you commit to them, and there's seemingly no conflict between this new "interest" feature and actually activating the elements. (Side note, I don't think <input type=success> is a thing.)

The invokertarget value should be an IDREF pointing to an element within the document. .invokerTargetElement also exists on the element to imperatively assign a node to be the invoker target, allowing for cross-root invokers.

I don't think this allows cross-root invokers, except in some cases. Note the complex conditions here.

If an element also has a popovertarget attribute then invokertarget must be ignored. interesttarget can exist on the element at the same time as popovertarget.

Thanks for considering what happens with both attributes present. I think it should likely go the other way though - if you have both, respect the new invokertarget and ignore popovertarget.

Loses/Lost Interest: The action of Loses Interest refers to the user "moving away" from an element...

It should be made clear that this applies to the pair of the invoker element and the target element. For example, a button that opens a popover - to lose interest while using a mouse, you'd have to de-hover both the button and the popover.

---

Overall, awesome proposal! I think it'd be a good idea to chat about this at an OpenUI meeting soon. I don't think I can Agenda+ it with any meaningful label, but would you mind if I get it on the next meeting's agenda?

[mfreed7]

Also side note: see w3c/csswg-drafts#9236 for a very related CSS proposal to control the delays associated with gaining and losing "interest".

[scottaohara]

would this cover a button that might need to have an associated tooltip, but also opens a popover, popover dialog, or modal dialog?

[Westbrook]

How could the platform support having other elements (e.g. Custom Elements) to be invokers as well?

[keithamus]

@mfreed7

I think you'd want invokeraction on just the set of things we currently allow, which are those "buttons" you listed, but only when they don't participate in a form in some way (submitting or resetting). Mostly, I think that's what you meant, I just wanted to be clear.

I'd like us to consider that <input type="reset"> could participate in a dialog form which would allow it to reset the form and close the dialog. I've updated the readme to reflect your comments though.

Here, I think you likely can add back <input type=reset> and buttons that do participate in form submission, since you'd like to use this feature to provide context for those actions before you commit to them, and there's seemingly no conflict between this new "interest" feature and actually activating the elements. (Side note, I don't think <input type=success> is a thing.)

I have no idea how input type=success came about. I guess ChatGPT isn't the only thing that can hallucinate prose 😆.

I don't think this allows cross-root invokers, except in some cases. Note the complex conditions here.

Thanks, added.

Thanks for considering what happens with both attributes present. I think it should likely go the other way though - if you have both, respect the new invokertarget and ignore popovertarget.

Yes that's a much better idea! Added.

It should be made clear that this applies to the pair of the invoker element and the target element. For example, a button that opens a popover - to lose interest while using a mouse, you'd have to de-hover both the button and the popover.

Great point! Added

Overall, awesome proposal! I think it'd be a good idea to chat about this at an OpenUI meeting soon. I don't think I can Agenda+ it with any meaningful label, but would you mind if I get it on the next meeting's agenda?

Please, this would be great to discuss further.

@scottaohara

would this cover a button that might need to have an associated tooltip, but also opens a popover, popover dialog, or modal dialog?

Yes I believe so:

<button interesttarget="my-tooltip" invokertarget="my-dialog">Tooltip on hover/focus, click to open dialog</button>

@Westbrook

How could the platform support having other elements (e.g. Custom Elements) to be invokers as well?

It's a good question, and one that seems to largely revolve around this big open question of "how can a custom element be a button". We could add something to .elementInternals() but that feels like it somewhat defeats the point of this being declarative. One solution without adding any new mechanics is to create an element that delegates focus to the button in its shadowroot, but that still requires imperative assignment if it wants to target a cross-root target.

This is all to say I don't have a good answer for this, and it might need addressing at a larger scope than this proposal.