openui / open-ui

Maintain an open standard for UI and promote its adherence and adoption.
https://open-ui.org
Other
3.5k stars 186 forks source link

[invokers] Implicit targets #1057

Open lukewarlow opened 3 months ago

lukewarlow commented 3 months ago

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.

scottaohara commented 3 months ago

seems like a good idea worth considering for those contexts.

zcorpan commented 3 months ago

Replying to @mfreed7 here instead (https://github.com/whatwg/html/issues/9625#issuecomment-2128160276)

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

@yisibl调用程序目前不适用于details。另请参阅whatwg/html#2272whatwg/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 commented 3 months ago

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 commented 3 months ago

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

lukewarlow commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.