nice, htmx is infiltrating into the browser standards
Invoker Commands API
11–16 of 16 posts
Re: Invoker Commands API
#12I just noticed, that Invoker Commands are available across all major browsers. Good to see that HTML progresses to make Javascript redundant for basic UX.
It's nice, but it's not quite ready for use yet. 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…
Yeah, this only gets interesting if they start contemplating native two-way binding, but that still wouldn't cover the vast majority of complex use cases that require computed values.
Re: Invoker Commands API
#13I just noticed, that Invoker Commands are available across all major browsers. Good to see that HTML progresses to make Javascript redundant for basic UX.
I've always browsed with javascript disabled but in the last few months (presumably in response to AI scraping) loads of sites that previously worked now don't. IMDB. Loads of open-source blogs, wikis and source repositories. Commenting on Wikipedia. Browsing job sites. It's never been easier to create a great site that doesn't require javascript, but hardly anyone is.
Google Search doesn't work without JS. I think we're actually moving in the opposite direction of what OP inferred. It's pretty difficult to reliably detect bots without using JS, and the vast majority of interesting client-side web applications are downright impossible without it. No amount of HATEOAS is going to make a usable version of Figma.
Re: Invoker Commands API
#14This is fine.
We’ve already had it as `label for=“form-element-id”`
Re: Invoker Commands API
#15I’ve been adding global listeners for click and keydown that call handleFoo(event) if event.target has a data-foo attribute.
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.
Re: Invoker Commands API
#16I’ve been adding global listeners for click and keydown that call handleFoo(event) if event.target has a data-foo attribute. 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…
O(depth) too, no? The events have to bubble up to the window before triggering your handler.