I guess the stylistic choice of separating content, style, and interactivity eventually became a convention to keep JavaScript isolated from HTML, but nowadays with Tailwind and HTMX, it does seem like at least some developers want everything in HTML, for the strengths you mentioned.
It's not supported on the previous main version of Safari, so everyone following the "last two major versions" of browser support rule can't use them.
Also, it's currently limited to only dialogs and popovers (and custom events, but in those cases you need js anyway).
It'll be more useful once it can control:
- details (open, close, toggle)
- video (play, pause, toggle play state, set seek point, mute, set volume)
- select (open/close widget, set/unset value(s))
- input (open/close widget, set/unset value(s))
- all elements (add/remove/toggle/set a class/attribute)
It's never been easier to create a great site that doesn't require javascript, but hardly anyone is.
People who disable JS are probably a very tiny minority and of those who consume ads, an even smaller one.
The Invoker API seems like a neater way of handling the same pattern but I’m biased towards global event listeners because they work automatically on newly injected markup and they scale O(functionality) as opposed to per element listeners that scale O(elements). I’ll be the first to admit that the latter is more of an aesthetic choice rather than being based on any kind of performance statistics.
Looks like safari shipped support in December though so now I can go nuts
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
We’ve already had it as `label for=“form-element-id”`