#920: Invokers API

Visit on Github.

Opened Dec 8, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of the "Invokers API", as described in the Open UI explainer.

Adding invoketarget and invokeaction 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 invoketarget will - when clicked, touched, or enacted via keypress - dispatch an InvokeEvent on the element referenced by invoketarget, with some default behaviours.

<button invoketarget="my-dialog">This opens a dialog</button>
<dialog id="my-dialog">This is the dialog</dialog>

While there are many ideas for what those behaviours will be, for the initial implementation we want to ship:

  • Showing, hiding and toggling popovers. (This is very similar to popovertarget).
  • Showing a Dialog as modal, and closing a dialog.
  • Explainer¹ (minimally containing user needs and example code): https://open-ui.org/components/invokers.explainer/
  • User research: [url to public summary/results of research]
  • Security and Privacy self-review²: See below
  • GitHub repo (if you prefer feedback filed there): https://github.com/openui/open-ui (please use the Invokers label)
  • Primary contacts (and their relationship to the specification):
    • Keith Cirkel (@keithamus), GitHub
    • Luke Warlow (@lukewarlow), Igalia
    • Mason Freed (@mfreed7), Google
  • Organization/project driving the design: OpenUI
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5142517058371584

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): OpenUI
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/openui/open-ui/issues?q=is%3Aissue+label%3Ainvokers
  • Major unresolved issues with or opposition to this design:
    • Mostly to do with the naming of the actions, and how they fit within the existing attribute naming scheme. At current we have showpopover, hidepopover, togglepopover, showmodal, close and auto. It seems as though these should include dashes, but we've reserved dashes for custom actions (see openui/open-ui#900 and openui/open-ui#969).
  • This work is being funded by: Keith Cirkel

You should also know that...

We are looking for help with resolving the naming of actions, and how we can best fit the existing system. We're explicitly interested in feedback from the TAG!

This works surrounds some larger work pieces, for example there is follow on work to add more actions, follow on work to add an interesttarget which will do the same but for hover/focus style interactions, and we are also looking to deprecate popovertarget in favour of this API. While we're not seeking review for those parts, I hope they can paint a broader context of what is planned here.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2024-02-26

Minutes

Is there a way to detect that this feature exists?

Why is there no generic .invoke() method for invocation targets? If targets have default action (called "auto"?) this might make it more ergonomic for authors rather than needing to work out how to achieve an action.

Why does <details> have "toggle" and "auto" actions doing the same thing?

Why does the <dialog> "toggle" action do the same thing as "cancel"? Why does this not show the dialog when it is not already open?

Is there a polyfill planned?

Does invoking alter focus? If something is invoked, does that receive focus? It seems like this would usually be the case, but some actions might not need that. Pausing a video doesn't need to draw focus, but you would want to focus <select> or <dialog> or a popover. Whatever the behavior is, it should be specified so to be consistent across UAs.

2024-03-11

Minutes

<blockquote> We're broadly in favor of invokers because it unifies some existing interaction patterns.

We feel it makes sense to have an invoke(action, invoker) method because it lays a path for future interactions with elements. We think that this might be more useful for custom elements or future features that are added to the platform.

We observe that a lack of additional arguments to invocations (or invoke()) are a concession toward the declarative nature of the core feature. Rather than a flaw, we see this as an important characteristic of the design. It simplifies this design and this characteristic seems like it is worth protecting. Richer interactions can remain the domain of script.

Having invoke() also helps discoverability. We think that this would be more useful if it were possible to get the list of available actions from elements.

(A footnote from me: when we ask questions, like the one above about focus, we appreciate your helpful answers. We appreciate those answers being added to documentation even more.)

</blockquote>