keithamusOpinion poll!
You have a <button>, it makes a <foo> open. What would be the best declarative attribute for the button to control the foo?
<button clickaction=open
<button invokeaction=open
<button command=open
Other (comment ideas)
Poll ended at .
Sara Joy 
@keithamus I'm slightly confused by this - would there then be another attribute that gives the id of the <foo> element?
@sarajw yes there would. It would likely be named similarly, so e.g. `clickactiontarget`, `invoketarget`, `commandtarget`, or similar.
@keithamus ok that makes sense :)
I don't much like the one with 'click' in it, as that's not the only way to activate a button.
They all seem so long, haha. Honestly otherwise however it's named I'd just be so happy to code stuff up like that. So neat. So simple!
@sarajw full disclosure we've been working on the idea for a while: https://open-ui.org/components/invokers.explainer
This is a last minute look at the API naming!
@keithamus thank you! Yeah if I was at my computer and not my phone I might have gone looking myself - you did post an article about it a while back I think? I love the whole thing.
@keithamus and can't we have the attribute be called `action` even if one already exists in <form>s?
So maybe like:
```
<button action="open" controls="my-dialog-id">Show options</button>
```
I guess for a dialog we might also have a "showModal" action available... 🤔
@sarajw it might be confusing with forms, but if I'm happy to try if there's a strong desire from the community.
@keithamus it just seems perfectly fitting to me. And I used "controls" because I was thinking of aria, but just target would be great.
Luke@sarajw @keithamus So one thing to add is there's a 2nd type of 'thingy' which acts on interest (hover/focus/etc) rather than invoke(click), and the idea is they could be used at the same time. Not to say 'action' is bad but it's worth considering that bit too.
@Lukew @keithamus interesting! Fair play, naming is hard and I'm an outsider just speaking my mind :)
I'm stoked for this though. Feels like how buttons *should* work. But if inline JavaScript was a security issue, how is this safer? Just a lot less flexible and more hardwired?
@sarajw @keithamus Fwiw showModal is one of the proposed actions :)
@Lukew @keithamus excellent, consider me fully on board, tell me where I can star/thumbs up/boost/comment to help it along, and I'm so there
@keithamus @Lukew then you're very welcome! I'm no authority but happy to help in any way
Stuart Langridge@keithamus I assume this would need some sort of pointer at the thing it opens? <button command=open for=foo> or similar? Then I think “command” is good because “invokeaction” is unbearably techie (and sounds like it’s trying to be “invocation”, which sounds a lot cooler (a magic spell!) but not very professional), “clickaction” isn’t really right (it’s not always a click, and the click event would be called something different if named today) and everyone knows what a command is
@keithamus (not sure about “for”. On the one hand it’s clearly the best name for it, which is why labels have it. On the other hand, htmlFor.)
@sil yes exactly. Likely the idref pointer would be named similarly, but wit `target` e.g. `clicktarget`, `invoketarget`, `commandtarget`.
Patrick H. Lauke@keithamus just "action" ?
@patrick_h_lauke action is viable but it _might_ get confused with `formaction=` / `<form action>`.
Nathan Knowler@keithamus I feel like `command` might have a bit of undesirable baggage w/r/t the content editable API.
I like “invoke” personally. Makes me think about the `__invoke` magic method in PHP (handles when an object is invoked as a function).
Alternatively, `actiontype` and `actiontarget`? `invokee` becomes an `actor`? `invoker` becomes a `director`? 🙃 Might be too confusing. I still find invoker clearer conceptually.
Tobias Bieniek@keithamus we already have type=button/submit/reset. would type=open be an option instead of adding another attribute?
@tb It's a little tricky but if that's a strong desire from the community I'm happy to pursue it.
@keithamus @tb Two downsides to this is it limits the feature (the auto action would be a toggle much like popovertarget rather than open), and also the button would fallback to a submit button in older browsers.
westbrook@keithamus the idea of
<button for=demo command=showModal>Show Modal</button>
<dialog id=demo></dialog>
Is quite clean. It does leave out the ability for “interest” to be registered against a different element/method however.
With that out of the way `invokeaction` and `interestaction` make lots of nice symmetry.
Amelia Bellamy-Royds@keithamus Is there a reason not to extend the existing `type` attribute?
type=submit
type=reset
type=open (or expand, maybe? if it's expanding something on the current page, to distinguish that from opening a new link)
@AmeliaBR @keithamus ooh that’s clever. I had not thought of that!
@AmeliaBR the reason it to allow for totally arbitrary values, so `type=frob` and so on. Ideally it should be named separately to avoid us clobbering the existing attribute name.
@keithamus @AmeliaBR but a button can only do one thing, right? If it’s a button type=prod then it can’t be a button type=open, and that’s good. I mean, what would button type=submit command=frob do? That feels weird.
@keithamus @AmeliaBR but it’s surely not type=(invent what you like) though? There will be specific commands which are defined to have specific effects on specific targets. Sure, some random website can put whatever it likes in type (or command) but it can always do that. If command can be anything, then we can never say after release that command=open opens a <details> because what if someone invented their own meaning for open?
@sil @AmeliaBR full disclosure; we have a full explainer: https://open-ui.org/components/invokers.explainer/. It allows for `(invent what you like)` (so long as it contains a dash), but it has built-in defaults (which don't contain a dash).
In that regard, `type=whatever-with-dash` would work. If there's a strong desire for it, I can propose it.
@keithamus @sil Oh, if custom types need to be a specific syntax, then that's not a conflict!
I go back to voting for extending type!
`type=widget-play` is a custom extensible behavior that triggers a registered function of some type
`type=play` is something that could be built in for audio and video elements (please!)
But `typetarget` doesn't work for the ID ref, so I don't know about that one. Maybe `buttontarget`?
@AmeliaBR @keithamus @sil One downside to extending type is that unknown types currently fallback to submit buttons. So if we suddenly change the semantics of the type attribute that might break the web...
That's not to say we should never have new types it's just that making type accept anything is probably a non-starter unfortunately.
@Lukew Oh, that's true. If you're adding a custom button within a form, to display a widget or a T&C dialog, you'd want an explicit `type="button"` to be sure a JS error doesn't result in an HTML submit.
(Making submit the default type, instead of button, is definitely one of those errors in the web platform that should be fixed by time machine, IMO.)
@AmeliaBR @keithamus @sil Yeah unfortunately I think it's because forms existed before scripts so buttons were always submit? Definitely would be nice to have required an explicit type and fallback to a no-op (type=button) state. Its definitely one of the more annoying platform paper cuts.
@keithamus @sil If it's designed to be an arbitrary name of a function/event to trigger on the other element, then yes, that's a very different API than adding new button types!
I'd go with the `command` / `commandtarget` attributes in that case.
I like the idea of using `action` for consistency, but formaction is a URL, so different.
PS I do hope it will also be possible to use a built-in function as the specified command, like play with a video element target, or open with a dialog target.
@keithamus @AmeliaBR so, there are three possible values for button type. Submit is incompatible with command so you can’t have both at once. Reset “tends to annoy users” (MDN). And “button” doesn’t do anything.
This feels very much suitable for overriding type for command :)
@keithamus @AmeliaBR falling back to submitting the form is what we want to happen, no? I add a button type=play for=myvideo to a form and somebody opens that page in IE10… it should probably submit the form, shouldn’t it? If it does literally nothing then older browsers have no way whatsoever of using that button?
@keithamus @AmeliaBR ah, so the pitch is that in a non-supporting browser, the button doing nothing is better than the button submitting the form? I can see that argument.
mattscheurich@keithamus
<button target="foo" action="open" on="click">@mattsch @keithamus What if we wanted it to do one thing on click (activation) and another on say "interest" (hover/focus/etc)?
@Lukew @keithamus I just thought as well about specifying multiple invocations. I think it is legal to use {attribute}:{index}={value} in XHTML? e.g.
<button
invoketarget:1="foo"
invokeaction:1="open"
invoketarget:2="foo-tooltip"
invokeaction:2="open"
invokeevent:2="focus mouseover"
invoketarget:3="foo-tooltip"
invokeaction:3="close"
invokeevent:3="focusout mouseout"
>
Here I'm specifying the button opens foo on default invocation (click or keypress), but it can also open/close a related tooltip when the button is focused or hovered (freewheelingly introducing a new attribute invokeevent to specify which event triggers the action).
@mattsch @keithamus I *think* in html that would parse as a 1 attribute (not sure if that's valid) inside the invoketarget namespace, like xlink:href. While it's powerful I think it's possibly too complex?
@Lukew @keithamus yeah, feels goofy having all that guff
@Lukew @keithamus the only other thing I could suggest for multiple different invocations is by separating by delimiter within attribute values:
<button invoketarget="foo; foo-tooltip" invokeaction="open; focus mouseover:open, focusout mouseout:close">
In this the suggestion is that the delimiter ; splits the target/action into array where index groups target/action. An additional delimiter of comma separates actions, and actions could be prefixed by the desired event(s) (separated by whitespace if there are multiple) with a : and the action:
{
0: {
invoketarget: "foo",
invokeaction: "open",
},
1: {
invoketarget: "foo-tooltip",
invokeaction: [
0: {
event: "focus mouseover",
action: "open",
},
1: {
event: "focusout mouseout",
action: "close",
}
]
}
}
Maybe that's overcomplicated too...
@mattsch @keithamus Our current plan is to have an invoke* and an interest* attribute set for the action and target and then you can have both. Not as powerful but not as complicated. That being said interest invokers (or whatever they end up being called) still has lots.of unanswered questions
@Lukew @keithamus seems like a much more elegant and less complicated solution that what I was thinking! Simple is best.
@keithamus ah, just saw the docs at https://open-ui.org/components/invokers.explainer/
I like the concept behind dynamic invocation that fits the action (e.g. click for mouse/tap, keypress for keyboard)
meduz'@keithamus With `<button popovertarget="target-id">` and `<foo id="target-id" popover>`, there’s no need for a new attribute.
The use case of your question is too vague for me.
@meduz the point is to replace `popovertarget` with something more generic that can be used for lots of different things, e.g. opening a dialog, playing a video, etc.
@keithamus Okay, got it. Then `invokeaction` seems a good one to me. And if the value can match the HTMLFooElement interface, it’s nice. And if it can allow for shortcuts (`invokeaction="show"` as shortcut for `invokeaction="showModal"`), it’s even nicer.
Ken Kinder 
@keithamus <button on-click=…>
schrotie@keithamus I'm all for writing valid html, so I'd always prefix custom attributes with data-. This use case can now oftentimes be addressed with standard popover markup. If you need to customize that, I'd do exactly that, if the behavior close enough.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover
If your use case is more in line with opening an accordion, there's the summary/details markup.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary
You can customize all that (e.g. with custom built in elements), but try avoiding reinventing the wheel.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover
If your use case is more in line with opening an accordion, there's the summary/details markup.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary
You can customize all that (e.g. with custom built in elements), but try avoiding reinventing the wheel.
@keithamus Sorry, I may have missed the point, that you are discussing a possible standard here, not some framework of your's. In this case, please forgive me for my smartassing about "data-" and possibly other remarks (haven't thought that through).