Open lukewarlow opened 3 months ago
seems like a good idea worth considering for those contexts.
Replying to @mfreed7 here instead (https://github.com/whatwg/html/issues/9625#issuecomment-2128160276)
For
invokeaction="close"
, can we makeinvokeaction
optional and implicitly point to the nearest ancestordialog
element? It would be nice to be able to use<button type="button" invokeaction="close">
in a dialog without having to add an id.This is an interesting idea. It has somewhat limited use cases I think, perhaps this (dialog close) is the only one? It would also make understanding the behavior a bit tougher: in most cases, an
invoketarget
is required or nothing happens. But in the one special case of a<dialog>
parent and aninvokeaction
attribute, you'd also get behavior. Feels a little too magic? Maybe not.
Implicit relationships are normal in HTML: form controls with a form
, labelable controls with a label
, td
elements with the appropriate th
(s). Various elements only support implicit relationships, like footer
, h1
, summary
, etc.
Explicit-only relationship include img usemap
, input list
, but I think those are because you wouldn't typically (or can't) nest one in the other. But a close dialog button would almost always go inside the dialog itself. Maybe less common for popovers to have a close button at all, but if they do it also seems natural to have it in the popover.
I think this would be very useful for <details>
, often Accordion components need to be customized with an icon and be clickable, not having to specify an id would be very handy.
https://ant-design.antgroup.com/components/collapse-cn#components-collapse-demo-collapsible
<details>
<summary>Summary Title
<button invokeaction="open">Toggle</button>
</summary>
Something small enough to escape casual notice.
</details>
Also, how do we disable the default behavior of the summary
so that only the button
takes effect.
@yisibl invokers currently don't work for details
. Also see https://github.com/whatwg/html/issues/2272 and https://github.com/whatwg/html/issues/10032
@yisibl调用程序目前不适用于
details
。另请参阅whatwg/html#2272和whatwg/html#10032
Currently invoketarget works in Chrome (with flag turned on)
Demo: https://codepen.io/yisi/pen/MWdbBrP
<details id="foo">
<summary>Summary Title
<button invoketarget="foo">Toggle</button>
</summary>
Something small enough to escape casual notice.
</details>
To clarify it's part of the prototype implementation (it's a separate runtime flag even) but invokers V1 will only include dialog, popover and custom actions.
Implicit relationships are normal in HTML: form controls with a
form
, labelable controls with alabel
,td
elements with the appropriateth
(s). Various elements only support implicit relationships, likefooter
,h1
,summary
, etc.Explicit-only relationship include
img usemap
,input list
, but I think those are because you wouldn't typically (or can't) nest one in the other. But a close dialog button would almost always go inside the dialog itself. Maybe less common for popovers to have a close button at all, but if they do it also seems natural to have it in the popover.
Yeah, fair enough. I wonder if there might be ambiguities in case there are multiple nested elements to which a single value of the action
attribute might apply? I guess you just choose the innermost nested such element. Perhaps this could work.
@keithamus any objections to trying to add that capability? Seems relatively straightforward, at least implementation-wise.
I think this would be very useful for
<details>
, often Accordion components need to be customized with an icon and be clickable, not having to specify an id would be very handy. @yisibl Also see whatwg/html#2272 and whatwg/html#10032
+1 that because of https://github.com/whatwg/html/issues/2272 we probably shouldn't try too hard to add this capability for <details>
. But I suppose if we generally support implicit (tree-based) relationships, then this might fall out and be supported. At least as well as buttons-inside-summary is supported.
Fwiw I think after discussions invokers probably won't be added for details, I envisage the stylability improvements will address most of the use cases and the a11y story with details + invokers isn't clear (they might be actively detrimental which I want to avoid). With all that being said that's tangential. If they are supported they would benefit from this ability.
I think for the ambiguous actions case as you say it would just be walking up the (flat?) tree to find the relevant target, Closest parent wins sort of algorithm.
Simon's point about buttons in vs out of a form makes a lot of sense to me. If we re-imagine a submit button as just being a type of invoker (which they effectively are), implicit targets suddenly seem obvious.
e.g. <form><button type="button" invokeaction="submit">Submit</button></form>
vs <form id="form"></form><button type="button" invoketarget="form" invokeaction="submit">Submit</button>
Now I'm not saying we should re-invent submit as an invoke action, I think reset and submit the ship has long sailed on. But from an API design perspective the symmetry is nice.
I agree with everything @lukewarlow said. Seems trivial to add and has a nice value add. In whether or not it should traverse the flat tree, my vote is flat.
Came up from Simon https://github.com/whatwg/html/issues/9625#issuecomment-2127063636
Seems plausible to do.
TLDR: If the button is in a dialog or popover and has an non-ambiguous action value then we don't need an ID ref.