Forking HTML into a static language doesn't make sense

We have so many custom UI Elements, because forms did and still do suck. RSS always had a back seat, because it always was second class in browsers. Semantic web died outside of search engines, because browsers did not offer features like "Save event to my calendar". And boy, have I been promised for a long time I might someday be able to sort HTML tables by click.

Just a non exhaustive list of my pet peeves, but there are many more examples.

WWW eventually pulled out into the lead, due largely to licensing considerations; WWW had been developed at CERN, which explicitly disclaimed any ownership over it, while Gopher had been developed at the University of Minnesota, which preferred to leave its ownership claims ambiguous. People gravitated towards WWW for the simple reason that they knew no one would sue them for using it.

As WWW's userbase grew, demand grew as well to add features to it. Mosaic added images and image maps; Netscape added JavaScript; and on and on and on. Eventually WWW grew to the ginormous, do-it-all system we know and (ahem) love today. Because Gopher had been left behind in adoption, it didn't have those pressures to extend its capabilities; it was free to remain the simple hypertext system it was in the early '90s.

I see a lot of people today point to Gopher as an example of what the Web should be. But this misses the point; the Web isn't what it is because of some design decision it made that Gopher did not, the Web is what it is because it had users. The more users there were, the more things people wanted to do with it; and the more things people wanted to do with it, the more features got tacked on.

If Gopher had been the one with the permissive licensing back in the '90s, it's very possible that it would have been the hypertext system everybody used, and today we'd be complaining about how complex Gopher has become and asking "hey, whatever happened to that toy Tim Berners-Lee was hacking on back in the day? Remember how simple that was?"

JS requires audit - even small script can game rank by encoding JS and CSS in other resources to pretend there is not much of it. Audit requires reproducible response, can be gamed, requires web of trust.

In the end it is all about goodwill, which may be hard to find in spyware ridden web.

There's a separate issue that a lot of stuff requires JS, but the JS mostly just calls JSON endpoints, so that's easy to scrape. The tricky thing is scraping ASPX sites that jump through a bunch of hoops instead of having a simple backend API.

Without the cooperation of my coworkers, bosses, and third party suppliers, very little of what I do will stick, and I have to be clever or at least subtle for that to happen. Any broad-stroke things like 'Just use HTML'? You've got to be kidding.

> persuading Web developers to use it is where the real problem lies

So what? There are various alternative markup formats, like Gemini, Gopher, Finger, Troff (used for Unix man pages), and perhaps we'd also count Markdown, and even RTF. Not every project aims for world domination. Websites interested in being lightweight, already can. HackerNews, Pinboard, and SourceHut, all manage it.

> getting your entire constituency to agree on a specific list of allowed features is going to be very difficult

Maybe so, but it doesn't sound insurmountable. This sounds no more challenging than any other committee-driven process.

> Video? Animated GIFs? CSS :hover? CSS media queries? Different people will give different answers to these questions.

My answer is no on all counts, for what it's worth. None of those things belong in a simple minimal document format.

> we could build a much more efficient browser (or browser mode) for that subset. As a former Mozilla distinguished engineer, I'm skeptical.

It's obvious that the system requirements for such a browser would be far lower than those of Firefox. We already have a project much like this in Castor. [0] I figure that's the point here. No-one is suggesting that Firefox, running on a modern desktop machine, struggles to render basic HTML. It's still heavyweight software though. The idea of running Firefox on an Arduino, for example, is laughable.

[0] https://sr.ht/~julienxx/Castor/

edit Forgot to mention, this question of subsetting HTML, vs using an alternative like Gemini in the Castor browser, cropped up in recent discussion at https://news.ycombinator.com/item?id=23165029

edit 2 See also Point 2.5, Why not just use a subset of HTTP and HTML?, at https://gemini.circumlunar.space/docs/faq.html

For better or for worse, this stuff is standardized via WhatWG & W3C as well as the three remaining browser engines (chromium, gecko, and safari) whose intersection of behavior is the de-facto reference and also what is driving standardization forward. Forking those definitely does not make sense unless you are the size of Apple or Google and more than one big company has backed out of pushing their own implementation (e.g. MS).

Most so-called full stack apps bypass the business of parsing of html5 & css in favor of just directly driving the DOM api. This provides greater flexibility and generally sidesteps a lot of complexity, bugs, etc. related to subtle differences between the 3 implementations. A typical index.html contains little more than the bare essentials to load the javascript; which then drives the DOM directly. This annoys some purists/traditionalists on the web definitely not in a position to fork or support their fork of any browser but makes little difference to search engines, users, or browser implementations.

So now having established that this is mostly an academic discussion of forking something that is highly unlikely to be ever actually forked (successfully), we can look at the underlying question.

This would be whether the DOM still an appropriate way to represent highly complex and dynamic applications that are not primarily documents and increasingly cover the whole range of any kind of interactive application possible (terminal UIs, windows based UIs, games, VR/AR, voice driven chat bots, etc.). For better or worse, most web development is about providing an illusion of more interactivity than a typical document would provide. The business of rendering static text to a browser is kind of a solved problem. It's everything else that's kind of hard to deal with via a DOM api. WASM is breaking this discussion wide open as suddenly people are porting decades worth of native code to run in a browser. Just because you can doesn't mean you should of course. But there's a lot of UI that can run in a browser that doesn't need or completely bypasses the DOM these days. Accessibility is a good remaining reason to still use it. But beyond that?

(I don't know how much of that is attributable to XSLT's nature, and how much of it is due to its relative obscurity. But it's certainly not a stack that I would choose for a new website based on that experience.)

Plus it did not help that the entire device rebooted on a markup parsing errors and such bugs.

Consider that these are the same devs complaining about the feature differences between Chrome and Firefox, let alone the vast majority of developers would consider targeting something like Internet Explorer 11 (which already contains A TON of functionality, WAY more than you'd need for a "trimmed down fork" and is still a VERY complex project if you wanted to make a full clone from scratch, despite it being a few years out of date) as something they'd do only in their worst nightmares.

This is why such propositions are hard. Well, that and all the existing web sites that use the existing tech, most of them not being made by huge corporations with big pockets and often are left alone to work with barely any modifications (web development is often made fun of for being too brittle, but this brittleness exists at the framework level, not the web browser level that has very strong backward compatibility).

Several people. If you follow HN and geek blogs, it comes up often...