HTML Can Do That

There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced).

Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-rendered pages with CSS styling and, perhaps, funny JavaScript that doesn't track me around.

Also, I wish Figma and Google Docs were just offline-usable desktop applications. Both are great _products_ and I use them, but using them on a browser tab makes me unhappy.

[0]: https://en.wikipedia.org/wiki/Game_theory

> Open one and the others close automatically.

I'm not sure that I've ever wanted this!! In fact, whenever I encounter something like a FAQ section where every single heading is its own collapsible, I typically expand all from the bottom up so that I can read everything without having to scroll-click-scroll-click etc. Whenever I encounter this behavior it's disgusting and user-hostile and I hate it.

The main thing I'd like to see HTML (maybe more accurately, without-Javascript) do is AI-bot protection.

Browsing the web with Javascript turned off makes things much more tolerable on my low-RAM computer. Until a year or two, I could access the vast majority of the sites that I cared to. With anti-AI-bot protection becoming prevalent, this has gotten a lot worse lately.

I've read somewhere that recent versions of Anubis support no-JS mode. I haven't seen it in use much yet. I wonder if that's because sites are still using old versions of Anubis, or because it's turned off by default in the new version, and sites haven't bothered to enable it, or some other reason.

One instance I've noticed is codeberg, which seemed to be using some no-JS-compatible bot protection -- I'm not sure if it is/was Anubis -- I don't use codeberg regularly (I haven't needed an account there yet), so I'm not sure about details.

Having worked on rich text editors for several years, I've developed a strong sense of the limitations of native HTML capabilities.

Popovers and dialogs are indeed useful; our project's color picker popup has been moved to a popover, which is much cleaner than manually managing z-index and closing it by clicking outside.

However, contenteditable is an exception. While it appears to be a native rich text editing capability of browsers, the implementation varies significantly across different browsers. The same operation will produce completely different HTML in Chrome, Firefox, and Safari. Not to mention mobile browsers with their various unpredictable input behaviors. This is why editors like ProseMirror and Wordgard don't trust contenteditable output; instead, they maintain their own document model and only use contenteditable as an input layer.

While native HTML capabilities are improving, for complex interactive scenarios, such as rich text editing and clipboard parsing, JavaScript is still essential.

And yet websites are going to do it with custom JavaScript anyway, because it's a nice excuse to force you to accept their surveillance^W analytics, which you will be enabling on the way. Oh, and also because shoving their BRAND™ in your face by micromanaging the appearance and behaviour of everything is apparently more important than user experience being predictable and consistent from one website to another.