I would strongly disagree with this, for two reasons.

1. Interfaces aren't special, the majority of application interfaces on my computer are just interactive documents, they're just styled to look like they're not. Outside of some specific examples (games, Blender, Krita, maps), I think very often if you can't sit down and describe an interface as pure text, something has gone wrong with your UX. And in fact, if you're interested in building genuinely accessible apps for low-vision users, it is a prerequisite that you be able to describe your interface using just text.

Most native apps are just interactive documents and forms.

2. The need to change presentation depending on context has gone up over time, not down. There's this theory that documents used to need to be flexible, but now we're all using interfaces where the data we're displaying should be tightly coupled to the interface and it just doesn't make sense given that screen sizes are far more diverse today (HDPI scaling is still a problem on Linux), phone sizes are more diverse, we have people using apps in hands-free settings, they're getting tied into personal assistants, we have more awareness now of accessibility concerns, devices like the Steam Deck exist.

Building polymorphic interfaces is more important today than it was 20 years ago when you could make 3 interfaces and just call it a day and assume you were supporting every device/control scheme. You didn't have people asking whether they could control your reader app with a gamecube controller.

And there are only two ways to build good polymorphic interfaces -- redesign multiple versions of the same interface, which doesn't scale and is guaranteed to leave uncommon and under-represented devices behind, or dive really hard into semantic[0] interfaces where you describe more precisely what data is rather than just what things look like.

The tight coupling of interfaces to presentation is usually bad for the end user and is usually unnecessary (in my opinion, based on the native desktop applications I commonly use). I often think that user interfaces would improve dramatically for everyone and our interfaces would be a lot easier to adapt to new computing interfaces and control schemes if we forced developers to build them with their monitors turned off, and then handed off the finished project to a separate team to make them look pretty.

----

I do agree with you on one point though:

> HTML wasn't designed for my ~modern assumption about what the document is. It was designed to be the document

HTML is at its best when it is not treated as a way to author interfaces, but rather as a render target in and of itself. A lot of design problems on the web stem from the fact that app developers view the pixels on the screen as their primary UX rather than as a secondary side-effect of their UX, which is HTML.

And I guess also to be fair, there is a valid critique here about the HTML "color" representing a mix of concerns. In some ways, HTML is kind of a flawed example of what we're trying to do. HTML was one iteration towards this idea of having user-facing data-driven interfaces. It's not necessarily perfect, it's just that it hasn't been supplanted (yet).

[0]: I understand you don't like the word (https://t-ravis.com/post/doc/semantic_the_8_letter_s-word/), but it's the best one to use here.