Making a more read/annotate/write web is near and dear to my heart. There's a lot I find admirable - noble about pages like Hyperclay!

But also, it's a distinctly different answer for each page to build its own toolkit for the user (Hyperclay) vs TBL's read-write web. The user-agent ought, imo, afford standard tools that are going to work across web pages, that extend the user agency whatever site they are visiting.

To add to that the W3C maintained the Amaya "browser", or web editor how they liked to call it, for like a decade and a half, as their vision for the web.

I think it was not just an appealing idea but Amaya itself was a solid implementation for a "testbed" (again, their words).

I can see why it died but I still think it is a bit of a shame it did.

Saving files locally was the same as saving files on the web in the original TBL context.

Imagine having a nice UNIX workstation on your desk at a university. This would resolve to machine.department.university.ac.uk rather than be hidden behind a router. If you wanted then you could run an x window on it or transfer files to and from it.

With standard issue Netscape of the era you could save an HTML file locally and it be fully accessible anywhere on the web.

The university would have the skills to setup the network for this, which was a difficult skill at the time.

In reality you would not save everything locally. The main department server would have a network share for you that would be mounted with NFS. So your files would be 'saved locally' over the NFS share to resolve to department.university.ac.uk/user.

You could also login to any workstation in the department for it to mount your NFS shares, with PCs of the era usually capable of running x windows and NFS in the university setting.

Servers physically existed in the server room rather than in the cloud.

I much preferred this model as, on SGI workstations, you had it all working out of the box. All you needed was some help with the networking.

Also important is that the web was originally all about structuring information rather than hacking it to make it pretty. It was up to the client to sort out the presentation, not the server.

In time we lost the ability to structure information in part because the 'section' element did not make it into HTML. Everyone wanted the WYSIWYG model that worked with word processors, where it was all about how it looked rather than how it worked.

We proceeded to make HTML that started as a soup of nested tables before the responsive design people came along and made that a soup of nested div elements.

Eventually we got article, section and other elements to structure information, but, by then it was too late.

It is easy to design something that is incredibly complicated and only understood by a few. It is far harder to design something that is simple and can be understood by the many.

We definitely lost the way with this. Nowadays people only care about platforms such as social media, nobody is writing HTML the TBL way, with everything kept simple. HTML has become the specialist skill where you need lots of pigeon holes skills. Nobody on these teams of specialists have read the HTML spec and no human readable HTML gets written, even though this is fully doable.

It seems that you are one of the few that understands the original context of HTML.

> web browser was also an editor

Ummmm all the browsers I know of are also editors... Are there any that aren't?

Edit - does no one use dev tools anymore? No HTML? No vanilla JS and CSS? Everyone just using TS, React and gluing things together? Like, you literally have an entire IDE in your browser (assuming you use anything derived from Chrome, Firefox or Safari) that can code a web page live...