whatwg/html

Add additional class based and data attribute based commands for Invoker API

Opened this issue · 8 comments

ggedde commented

What problem are you trying to solve?

Have the ability to toggle ANY element using css without needing javascript.

What solutions exist today?

  • Use javascript
  • Use checkboxes and a lot of custom markup and css.

How would you solve it?

Currently the Invoker API allows for commandfor and command, but the list of supported properties does not currently include the ability to support any element, nor does it provide any support for custom classes.

add commands:

  • [add, remove, toggle]-class[class-name]
  • [add, remove, toggle]-attribute[attribute-name]

This would allow you to use this on any element.

<button command="toggle-class[show]" commandfor="my-custom-modal">Toggle Modal</button>
...
<div class="modal" id="my-custom-modal">
  <button command="remove-class[show]" commandfor="my-custom-modal">Close Modal</button>
   ...
</div>

I don't want to use <dialog>

Toggle Dark Mode

<body id="my-body">
  ...
  ...
  <button command="toggle-class[dark-mode]" commandfor="my-body">Toggle Dark Mode</button>
  ...
</body>

Toggle Attributes 
<button command="toggle-attribute[readonly]" commandfor="my-custom-input">Restrict Editing</button>
...
<input type="text" id="my-custom-input" />

Toggle State Modal From SVG Map

<svg>
  <g id="WA" command="toggle-class[open]" commandfor="wa-modal">
    <path></path>
    <path></path>
  </g>
</svg>
 
<div id="wa-modal">
   ...
</div>

Anything else?

It is safe to say that everyone is excited about the invoker API, but i was shocked that there was no support for having the ability to toggle any element. Thus still making it required to use javascript to do so. I think one of the main reasons for the Invoker API is to reduce the use of javascript.

There are commands for open, toggle, etc, but they only relate to <dialog> or other popover elements.
You can use toggle-popover on any element, but requires you to add popover to your element which can lead to additional conflicts with css (overlay, positioning, etc)

Now if open, toggle, and close can also be used on any element and it just toggles the open attribute then I think that would solve this issue for the class based toggles as we could target that with css with [open], but I don't think this will get implemented and as far as I know that would not be valid html as the open attribute is only valid on certain elements or requires you to use popover which has limitations as mentioned above.

Thanks,

scottaohara commented

sounds like some of the things you're looking for are called out in this other proposal - #10499

ggedde commented

@scottaohara, thanks, yeah, I think those are great, but still require the use of <button> and don't allow for any element. I can personally see myself using this on other tags like <article>, <div>, <span>, <label> or a particular <path> element inside an SVG, etc.

scottaohara commented

thanks, yeah, I think those are great, but still require the use of <button>

that wasn't clear to me, that you dont' want to use buttons, from your examples. since they all use buttons. i'm dubious to the necessity of allowing a commandfor attribute to be declared on an otherwise non-interactive element.

regardless, i think there's probably some good overlap between these. Especially since what you're suggesting would likely need to align to one of the 'types' of toggles for accessibility purposes that are outlined in that other issue. i see you've already commented over there though, so that's all from me for now then.

  • 👍1
ggedde commented

that wasn't clear to me, that you dont' want to use buttons, from your examples. since they all use buttons.

Good call, just added an SVG example.

scottaohara commented

looks like that SVG example would necessitate some extra ARIA, keyboard behavior, and potentially JS to properly function for everyone. doesn't seem that compelling of a case if someone would still have to do all those other things as well. but, that's just my opinion.

zcorpan commented

I think we shouldn't add declarative "command" features on non-interactive elements, since that means accessibility is not built in, or we would magically add behaviors such as focusability etc which could be unexpected.

  • 👍1
ggedde commented

@scottaohara @zcorpan I thought the Invoker API would automatically add Aria attributes to the Accessibility API. That is what I would expect here. I agree that if it does not, then this would indeed require additional work via JS, etc.

Forgive me, but I thought one of the main reasons for the Invoker API is to reduce the need to add custom JS and to help with DX.

With that said is there any way now or future plans to toggle a class for any element without the need of JS. If not, then I think there should be. Even if it does not add accessibility and allow the Developer to work on that as another phase. I understand that accessibility should be high priority, but shouldn't that be on the developer and not a restriction on DX?

scottaohara commented

@ggedde that's why invokers are specific to button elements, for now. because the accessibility of how they would work with buttons is known / there are mappings that can be made automatically. putting such attributes on arbitrary elements would not come with automatic accessibility, because there are no consistent / expected mappings which would work for all elements - nor are many non-interactive elements expected to be keyboard focusable.