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 .
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 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.
Stuart Langridge@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`?
Luke@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.