[invokers] Implicit targets

[lukewarlow]

Came up from Simon whatwg/html#9625 (comment)

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.

[scottaohara]

seems like a good idea worth considering for those contexts.

[zcorpan]

Replying to @mfreed7 here instead (whatwg/html#9625 (comment))

For invokeaction="close", can we make invokeaction optional and implicitly point to the nearest ancestor dialog 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 an invokeaction 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.

[yisibl]

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.

[zcorpan]

@yisibl invokers currently don't work for details. Also see whatwg/html#2272 and whatwg/html#10032

[yisibl]

@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>

[lukewarlow]

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.

[mfreed7]

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.

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 whatwg/html#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.

[lukewarlow]

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.

[lukewarlow]

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.

[keithamus]

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.