[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.

[scottaohara]

@keithamus so that helps clarify a bit, but i'm still not sure what type of dialog is going to be invoked from that. a non-modal, a non-modal popover (in the top layer) or a modal dialog. I've looked at the InvokeEvent table from the explainer, and i'm seeing an expectation that something is a popover, or a modal dialog, but not a non-modal dialog (popover or not).

is the intent for interest largely for tooltips? or is there the possibility that other types of content could be shown/hidden if associated in that way? not for or against whatever answer is given, just want to understand the potential UX ramifications of a dialog or large block of content showing up on someone simply trying to tab through an interface. Understanding this would also result in any accessibility properties that would need to be exposed for the interesttarget attribute

Two other bits:

1. i assume this proposal would potentially overlap/negate the need for Consider "toggle" (e.g., show/hide - expand/collapse) button or attribute  openui/open-ui#700 (if so, great!)
2. i'd like to propose some updates to the accessibility section (specifically the implicit ARIA attributes). I assume it's ok to make a PR against your explainer, or would it make sense to talk that section out? Maybe it's better to talk it out at some point, rather than assume i understand the whys behind some of those choices?

[keithamus]

so that helps clarify a bit, but i'm still not sure what type of dialog is going to be invoked from that.

I've ignored the concept of non-modal-non-popover dialogs, and so an invokertarget pointing to a <dialog> (with no popover) will call showModal(), and <dialog popover> will call showPopover(). I'm making the assumption that we'll one day resolve #9376 and <dialog>.show() will be deprecated.

is the intent for interest largely for tooltips? or is there the possibility that other types of content could be shown/hidden if associated in that way?

Largely for tooltips. I can't think of a compelling use case that would not be disruptive to folks for anything else, but I'm hoping if there are some, someone will come forward with them.

i assume this proposal would potentially overlap/negate the need for Consider toggle (expand/collapse) button or attribute openui/open-ui#700 (if so, great!)

I think so! It seems like spiritually these issues align. I want this proposal to effectively capture/replicate/explain any built-in interactive element, including <details>. I've not done extensive research into what else conceptually uses aria-expanded but if I've missed any that you think warrant adding please do submit a PR! The table in the proposal is an attempt at an exhaustive list but was mostly drawn up from memory so I'm sure I've missed stuff.

i'd like to propose some updates to the accessibility section (specifically the implicit ARIA attributes). I assume it's ok to make a PR against your explainer, or would it make sense to talk that section out? Maybe it's better to talk it out at some point, rather than assume i understand the whys behind some of those choices?

Absolutely please do! It's safe to assume that the whys behind my choices come from a place of ignorance and doing what I think is right without any hard research.

[scottaohara]

thanks for all that, @keithamus

your response about the non-modal dialog makes sense now with that context - as it didn't initially click to me before that <* popover> the asterisks would handle the dialog popover use case. I had just read that table as "popovers" and "dialogs" as separate things. error on my part. Re: the linked issue, I've been thinking a lot about what Domenic mentioned in that thread - the use case for a non-modal dialog needing to not render in the top layer... and I can't shake the idea that there's something to that.

I think so! It seems like spiritually these issues align

that was my read as well, which is great. I'll definitely come back and kick the tires on this some more, especially re: the next bit about updating some of the accessibility bits. Which truly thanks for even considering that stuff. It's mostly nits / suggestions to either match reality, or use this as an opportunity to force support / update the spec for a certain attribute.

i'll put this on my todo to do another review / make a PR. Thanks!

[mfreed7]

is the intent for interest largely for tooltips? or is there the possibility that other types of content could be shown/hidden if associated in that way?

Largely for tooltips. I can't think of a compelling use case that would not be disruptive to folks for anything else, but I'm hoping if there are some, someone will come forward with them.

One such use case is a nested menu. (Try Google Docs for this exact behavior.) Click to open a menu (e.g. File), then hover over one of the items with a sub-menu. The sub-menu shows up after a slight delay. Note that their keyboard behavior is different - focusing on the item does nothing, and you have to hit the right-arrow to open the sub-menu.

[mfreed7]

Note that their keyboard behavior is different - focusing on the item does nothing, and you have to hit the right-arrow to open the sub-menu.

I suppose if we go with interesttarget that means hover, focus, or long-press, and someone wanted the above behavior (only trigger on focus, because they've handled the other modes themselves) then they'd need to do something like preventDefault() on the appropriate events? That's a bit of an issue now because focus is not cancelable. Is there another suggestion about how to give interesttarget more configurability?

[scottaohara]

thanks @mfreed7 - yes that's a good example, and a good reason why hint would have been a weird name for this type of popover. but yeh, per that google file menu example, it seems to me that hover is more of an 'enhancement' to that menuitem, as really someone should be able to tap/press on that using a touch device to open, since 'hover' and 'focus' may not even be things one can do if using a touch device, for example.

[josepharhar]

This was discussed at OpenUI today: https://www.w3.org/2023/08/31-openui-minutes.html#:~:text=openui/open%2Dui.-,Invoker%20Buttons%20%2D%20allowing%20popover/dialog%20and%20more%20to%20be%20invoked%20without%20JS,-masonf%3A%20this

[mfreed7]

So as mentioned above, we discussed this today at OpenUI, and the general tone was that this new proposal is generally a good direction to try to go. It has the flexibility needed to support many different element types, and it's expressive enough to work for many common use cases.

One point was made that the interesttarget part of the proposal still has some open questions, e.g. the particulars of the long-press behavior. It might be worthwhile splitting the proposal into two pieces, one for invokertarget which seems implementable and standardizable today, and one for interesttarget which needs more research on a few things.

What do folks think about this direction? @annevk @ntim @emilio

[nt1m]

General idea seems like the right way to go, though there's probably some bikeshedding to be done around naming and smaller details.

[mfreed7]

General idea seems like the right way to go, though there's probably some bikeshedding to be done around naming and smaller details.

Great! Do you think it's close enough that someone (@keithamus ??) should start drafting a spec PR? We're happy to prototype for Chromium. I do think we should just tackle invokertarget and not (yet) interesttarget to simplify things at first. Alternatively, two PRs could be drafted, one for each, and we could debate the issues around interesttarget via the PR?

My points of bikeshedding:

• invokeraction=opendialog should just be invokeraction=showModal. As much as possible, the action names should match up with their JS counterparts.
• Similarly, I'd prefer invokeraction=close for closing dialogs, invokeraction=open and close for opening and closing dialogs, invokeraction=pause and play for videos. The action doesn't need to include the context (e.g. play instead of playVideo), and it's ok for multiple types of targets to support the same action name, like open.

[keithamus]

Happy to work on specs and implementations.

I think your bike shedding points make sense and I agree with them; I was just being conservative in the explainer 😜

[josepharhar]

I'm not sure if these have already been discussed or not, but these feature requests for popovertarget should also be considered for this new attribute:

• Support popovertarget on custom elements with role="button"  #9110
• popovertarget and shadow DOM #9109

[mfreed7]

As I mentioned during the meeting, I think we should figure out a way to get to a place where the attribute you always need to supply is the short one. When you encounter a set of identically-prefixed attributes it would be rather unnatural for the shorter one to be the optional one. For instance, clickaction=IDREF and clickactiontype=ENUM could maybe work. Or command=IDREF and commandtype=ENUM.

All things equal, I agree that a shorter name is better. But I think here all things aren't equal, since this feature is somewhat nuanced and semi-novel, so clarity should trump brevity. I am biased, but I think popovertarget does that really nicely. It'd be nice to choose a name that has a "target" suffix, because that makes it relatively clear that the value of this attribute is the target of some action. Names like command=foo, while shorter, aren't very clear what they mean. Is the command "foo"? I can see people reporting bugs like "My <button command=showpopover> isn't showing the popover!". Just target=foo could work, but also feels a little ambiguous - it'd be nice to have a prefix that is common with the action, to tie the two together.

These are all just my opinions. I'm happy if we can reach agreement on any reasonable set of names.

For instance, clickaction=IDREF and clickactiontype=ENUM could maybe work. Or command=IDREF and commandtype=ENUM.

Let me know if you think these need to be added to the list above - happy to do so.

[mfreed7]

For instance, clickaction=IDREF and clickactiontype=ENUM could maybe work. Or command=IDREF and commandtype=ENUM.

Let me know if you think these need to be added to the list above - happy to do so.

I've updated my comment to include these two.

---

Any further suggestions for other names from anyone?

[zcorpan]

I agree with @mfreed7 that command=foo where foo is an idref, rather than an enum, is unexpected. Usage of "data-command" is mostly for the type of command; see GitHub code search.

[muan]

I tend to agree with developer feedback from #998, the term invoke introduces unnecessary technicality IMO, especially to non-english speakers. Something using click resonates better, but I'm open to other ideas.

Just gonna echo @nt1m's concern here re: non-English speakers. That was my gut reaction regarding invoke as well. It is a word that perhaps only top 10% English speakers where I am from would understand.

But that being said, I too have concern with basing the name around click furthering the confusion around whether something is activated via click. click has misled many devs to think doing <span onclick> is enough to replicate a <button>, for example.

Anyways, in the hope of supporting the non-English speaking community claim, I ran polls on Mastodon and Twitter as well using Traditional Chinese (of which most if not all responders were Taiwanese). I know it's very much not big enough of a sample size but so is the nature of non-English speaking community feedback in general. I suspect a poll done in Japanese/Korean would yield similar results.

	@keithamus' poll in English	@muan's poll in zh-TW
<button clickaction=open	157 (26.3%)	23 (67.6%)
<button invokeaction=open	187 (31.3%)	3 (8.8%)
<button command=open	143 (24%)	6 (17.6%)
Other (comment ideas)	110 (18.4%)	2 (5.8%)
Totals	597	34

Lastly, I saw that toggle has been mentioned a few times, and being referred to specifically as a separate proposal, but I am not seeing a significant difference between a <button toggle> and this proposal (Keith's polyfill demo does a toggle for both popover and dialog). It seems like the main difference is that popovertarget don't current toggle aria-pressed according to @lukewarlow, but shouldn't it? In brief testing I do see expand state being changed but not pressed state. @scottaohara I am curious if you have opinion on whether pressed state should be updated since the popovertarget and this proposal do both essentially perform a toggle.

I personally think toggletarget / toggleaction makes sense to me and explains the state change clearly. Unless there is a use case where we want the invoke button to only act like a one way street. But so far I don't see that being presented as a use case?

Sorry to be chiming in so late and excuse me if I have missed some context and of why the above isn't valid. I haven't been following these discussions as close as I would like.

[lukewarlow]

Firstly a big thanks for running that poll, it's useful to have those sorts of data points when coming up with these decisions.

As for the latter part, yes in its current form it's mostly toggling expanded states (though there are actions for explicitly closing or opening). But there's future aspirations for actions that aren't related to toggling the element's expanded state. Media controls for example. So toggle probably doesn't always work. Toggle is also a very overloaded term like you say. While I won't speak for Scott my understanding is that the aria-expanded state is instead of the aria-pressed state, so pressed wouldn't be appropriate here.

[muan]

Thanks for accommodating my belated contributions!

yes in its current form it's mostly toggling expanded states (though there are actions for explicitly closing or opening).

It sounds to me that this proposal especially with its initial problem statement and examples, should be primarily focusing on toggling (popover/dialog) as opposed to invoking, no?

IMO it should be make clear if this goes through, whether there is still space for a toggling attribute to be proposed; and if it does, why wouldn't dialog/popover users use that instead of invoke(or whatever it'll be called).

But there's future aspirations for actions that aren't related to toggling the element's expanded state.
...
my understanding is that the aria-expanded state is instead of the aria-pressed state, so pressed wouldn't be appropriate here.

That makes sense. Thanks.

Seeing the defaults it seems to me that aria-pressed should also be implicitly applied for eg playpause/play, like toggle+aria-expanded with popover/dialog/details, one direction or not. Should they not?

[scottaohara]

thanks for covering the question, @lukewarlow. yes, we only use an expanded state for popovers/dialogs (truly, we don't 'need' the expanded state for modal dialogs - but that's off topic for now)

Re: play/pause, @muan. I've mentioned this a few times in related issues for 'toggling' - but if the name of the control changes (play/pause) then it is not desired for there to also be a state change that would too be announced to users. aria-pressed state changes should occur if the name of the control remains unchanged. Like a bold button being in a pressed / not pressed state. But a button that toggles between a name change of "play" and "pause" should instead be firing a name change event

[muan]

I've mentioned this a few times in related issues for 'toggling' - but if the name of the control changes (play/pause) then it is not desired for there to also be a state change that would too be announced to users.

I noticed. And I believe the proposal here does not include changing the name when the function is called, so it seems to me aria-pressed would be ideal? i.e. if a button command=play is pressed, it should have a pressed state in the accessibility tree.

[scottaohara]

hmm. maybe i'm inferring something from that table that i shouldn't be. the default video and audio elements do have buttons that have a name change and not a state change. maybe i'm incorrect to assume that people would be making name change events with those types of invokers.

if i'm wrong, then i see your point. though i guess i wonder if this aspect of the proposal is 'done' then? since the majority of play/pause, mute/unmute handle state via name change and don't use aria-pressed - if this was to use aria-pressed and not have a name change event occur, then it seems like it wouldn't actually be doing what people generally would want it to.

[muan]

i wonder if this aspect of the proposal is 'done' then? since the majority of play/pause, mute/unmute handle state via name change and don't use aria-pressed

This is pretty much my concern and is tied to "whether this should just be toggles", since the proposal does include non-toggling events.

I assume a button command=play wouldn't have a name changed to pause since it isn't a toggling action like command=playpause. Which then also makes me wonder if this state is to be changed if other events were triggered to change the play/pause state of the same targeted element.

[lukewarlow]

Regardless of the media controls discussions (which are helpful so thanks!) these actions are also designed to have custom values which won't always fit into the toggle nomenclature. You've also got potential ideas (again just ideas not saying they're good or will happen) of stuff like a copy action or full screen actions.

[muan]

I think the idea of a Swiss Army knife of an invoker does sound good, but in practice each of these actions has their corresponding accessibility requirements. Is the idea to have developers do the extra work (either name/state change or providing function eg copy invoked successfully feedback)? If so that would unfortunately mean that this native HTML feature would not be fully accessible without JavaScript except for when it is used with a few special elements/commands, and developers will need to know the nuances for all the different commands and element pairings.

Like you said, these might or might not happen. But by leaving the door open for now, it creates complications, since the spec can't specify the state or name change requirements for assistive technologies for all the commands, for flexibility sake. It also affects how this attribute should be named.

[lukewarlow]

The built ins should provide as much accessibility as possible, but for custom actions that's up to the developer but they'd need JS to handle the invoke event anyway.

But for example if their custom action should toggle the pressed state that's something that we should address at the platform level separately (in fact I have a proposal for doing just that).

[lukewarlow]

because the spec can't specify the state or name change requirements for assistive technology for commands, for flexibility sake.

It can based on the chosen action, custom actions have naming requirements for compatibilities sake. So there's nothing we can't do wrt to accesibility.

[domenic]

Are custom actions included in the current PR? I thought everything except dialog/popover/details was removed for now. Which makes me very sympathetic to @muan's points.

[lukewarlow]

Are custom actions included in the current PR? I thought everything except dialog/popover/details was removed for now.

My understanding is that custom actions are included. Details aren't though. Cc @keithamus to confirm my understanding

[keithamus]

It's popovers, dialogs and the "custom actions". We're confident that we can get a11y right for popovers & dialogs, and we think custom actions should make no accessibility affordances as they'll require JS to handle the action anyway. For each built-in addition our intent is to ensure that the right state changes take place to make the default behaviour accessible by default.

While I appreciate that invokers aren't tied to button state changes, I'd contest that feedback mechanisms are varied and a large amount of interactions won't be tied to a state change on the button itself. For example focus changes are a form of feedback where applying state changes to the button are effectively pointless. Similarly, announcements such as aria-live changes (or the upcoming ariaNotify) can announce the action rather than a button state change.

[muan]

To clarify, there are 3 types of commands:

1. Collapse/expand toggle (included in this proposal): popover/<dialog>
2. Custom action (included in this proposal): user coded, listening on invoke event instead of click.
3. Further (HTML) behaviors (aspirational)

---

For type 1: collapse/expand toggle

Looks like my question regarding future collapse/expand toggle proposal is answered in the explainer:

It is, however, intended that invoketarget will replace popovertarget leading to popovertarget’s eventual deprecation.

For type 2: custom actions

"custom actions should make no accessibility affordances as they'll require JS to handle the action anyway"

According to the explainer, Mostly a QoL upgrade for framework users? I am personal unfamiliar how much benefit this yields, but I do feel like there are downsides by combining this with type 1 and 3 which should work without any user JavaScript.

For type 3: Further behaviors (media controls / pressed toggle, etc)?

Aspirational. Since most are HTML behaviors, I believe they all have corresponding accessibility requirements, some one which may be addressed by the newly proposed openui/open-ui#1058. @keithamus what do you think about my comment regarding the flexibility leading to complications, especially with regards to naming? Given current invoker's all-encompassing nature, the attributes need to be named vaguely, while doing very specific yet implicit things depending on the targeted element.

[mfreed7]

A few notes here:

• OpenUI just had a great discussion around the naming for this feature. Please see that discussion at: [invokers] bikeshed the attribute names. openui/open-ui#998 (comment)
• Based on the discussion, I just updated my comment above to:
  • Remove invoke as an option, since there's strong pushback from WebKit and others.
  • Add a new suggestion of controls=idref.
  • Add a few new suggestions replacing target with either for or id.
  • Those are what came out of our brainstorming, but obviously if there are other latent words we should be considering, please suggest them.
• We also discussed Toggle Button Proposal openui/open-ui#1058 which is specifically about the "toggle" behavior that is partially being discussed in this issue. I'd love it if we could separate out the discussions for these two features, and ideally move the toggle discussion to Toggle Button Proposal openui/open-ui#1058, and keep this discussion just about the naming of the attributes.
• Finally, I'll just say that Chromium is supportive of any reasonable name. But we strongly believe that this feature is a good one and deserves to land in standards and browsers. So I'd like to ask that specifically @zcorpan @annevk @emilio and any other implementers with strong opinions on naming can list which of the suggestions they can live with, so we can see if there's common ground?

[zcorpan]

id suffix is inconsistent with at least Microdata itemid (which contains an identifier, not an idref).

controls is interesting, but also looks like the plural form of control so could be confusing. Note that video has a controls attribute.

For names with click, I expect ongoing confusion about whether it's pointer device only or not.

Options 5 and 7 are ok, and prefer 7 because it's shorter.

5. <button commandtarget=idref> or
   <button commandtarget=idref command=showmodal>

7. <button commandfor=idref> or
   <button commandfor=idref command=showmodal>

[mfreed7]

controls is interesting, but also looks like the plural form of control so could be confusing. Note that video has a controls attribute.

Quick note that this being the plural form of control was the intention. As in, "this button controls that item". But I do agree that's subtle, likely more so for non-native English speakers. And the confusion with <video controls> also isn't great.

Thanks for the other opinions.

[domenic]

Quick note that this being the plural form of control was the intention. As in, "this button controls that item".

Your usage here is not pluralizing the noun "control"; it is the third-person singular present tense conjugation of the verb "to control". Subtle even for native English speakers! :)

[mfreed7]

Your usage here is not pluralizing the noun "control"; it is the third-person singular present tense conjugation of the verb "to control". Subtle even for native English speakers! :)

Ha! You’re of course right. I wrote that comment quickly and just went with “plural” but should have said “verb”. I’m almost embarrassed enough to delete my comment, but I won’t, for context. But this further indicates that “controls” is not the strongest choice. 😄

[Westbrook]

There's at least some prior art for controls (with an "s") by way of the aria-controls attribute, which shares a lot with the intent that we have for this attribute...

[mfreed7]

I've heard one vote for this:

<button commandfor=idref> or
<button commandfor=idref command=showmodal>

That's nice and short, it has a suffix (for) to make it clear that the value is the target, and it doesn't confuse people with "click". I would be perfectly happy with this choice. @keithamus any objections?

@annevk could you live with commandfor/command?

[keithamus]

After discussing with @annevk and @lukewarlow I think we will look into the following steps:

• Remove implicit actions
• The action attribute will be command
• The target attribute will be for
• We will look at implicit for post v1

[mfreed7]

• Remove implicit actions

"Implicit" is overloaded. Do you mean the implicit where commandfor is not needed if the button is nested inside the target element? Or do you mean the implicit where command is not needed, e.g. where <button commandfor=popover> has an implicit action of togglepopover?

If it's the former, +1 from me, that can be added later. If it's the latter, that would be an unfortunate loss of functionality, and I'd love to hear more about that.