Forking HTML into a static language doesn't make sense
robert.ocallahan.org
Forking HTML into a static language doesn't make sense
1–10 of 94 posts
Re: Forking HTML into a static language doesn't make sense
#2Forking HTML might not make sense indeed, but I think this post doesn't make a compelling point as to why or why not.
Re: Forking HTML into a static language doesn't make sense
#3Seems easy to define such a fork: disable JavaScript, and load all resources immediately and unconditionally to disable tracking based on what is visible.
To prevent custom UI, also disable CSS and use a decent default stylesheet (e.g. the reader mode one or a Markdown one).
Re: Forking HTML into a static language doesn't make sense
#4Seems easy to define such a fork: disable JavaScript, and load all resources immediately and unconditionally to disable tracking based on what is visible. To prevent custom UI, also disable CSS and use a decent default stylesheet (e.g. the reader mode one or a Markdown one).
Yes, the post says exactly that - forking the HTML is easy, the hard part is convincing developers to use that fork instead of the more featureful "mainstream" version.
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).
Re: Forking HTML into a static language doesn't make sense
#5Seems easy to define such a fork: disable JavaScript, and load all resources immediately and unconditionally to disable tracking based on what is visible. To prevent custom UI, also disable CSS and use a decent default stylesheet (e.g. the reader mode one or a Markdown one).
Yes, the post says exactly that - forking the HTML is easy, the hard part is convincing developers to use that fork instead of the more featureful "mainstream" version. 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 functio…
You don’t need to convince existing developers to adopt it. Remember the early web spirit, where people imagined that everyone would run their own server and publish their own homepage? Turns out it was way too complicated to do, and required you to be a tech enthusiast. Largely, I would say, because HTML was not designed to accommodate for a lot of the things people immediately wanted to do. Even a basic thing like keeping navigation consistent across the multiple pages is impossible.
I think if you designed a document language that took advantage of 30 years of experience of what people actually want to do on the web, you could find an entirely new set of users. People who want to feel ownership of what they publish, want to be able to be creative and improvise, but don’t have the technical skills to create a site in the current web stack. It would probably look more like a social media service, so it could run on top of the web as it is now, or have dedicated native clients.
Re: Forking HTML into a static language doesn't make sense
#6Forking HTML might not make sense indeed, but I think this post doesn't make a compelling point as to why or why not.
The article offers a few reasons but they strike me as weak sauce.
> 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
Re: Forking HTML into a static language doesn't make sense
#7The Gophersphere seems to prosper and I have seen some interest in Project Gemini[0] over on Mastodon in the last weeks. So I guess People are trying and somewhat succeeding.
Personally, I am also quite skeptical of the benefits of these approaches. I would like a web more focused on documents, but many of the "forbidden" features these communities define are actually things I was excited about when they were introduced and still would not want to miss on the web. At the same time, just limiting the technology will not make it magically better.
I would love to see more experimentation towards more hypertext and the things it could offer to the user, but just using a subset of old technology seem not really like a great way forward.
At the same time, why can having a cleaner, more performant web not be a social movement amongst developers? I still remember when many of our websites features "Valid XHTML" or "Made with Web Standards" Badges, to show our peers and the world what was important to us. Maybe setting some rough guidelines what we envision a modern, performant and user respecting web to be and whipping up a few badges to show our colors could get as further then trying to reinvent the technology from scratch?
Re: Forking HTML into a static language doesn't make sense
#8Earlier quoted context omitted.
Yes, the post says exactly that - forking the HTML is easy, the hard part is convincing developers to use that fork instead of the more featureful "mainstream" version. 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 functio…
You don’t need to convince existing developers to adopt it. Remember the early web spirit, where people imagined that everyone would run their own server and publish their own homepage? Turns out it was way too complicated to do, and required you to be a tech enthusiast. Largely, I would say, because HTML was not designed to accommodate for a lot of the things people immediately wanted to do. Even a basic thing like…
Honestly, this 'entirely new set of users' sounds like wishful thinking for a problem that does not exist as you describe it.
Back in the early web people couldn't run their own server not because HTML was hard (WYSIWYG editors not only existed since the Windows 3.1 days, but they were very widespread at the time - Netscape Gold even came with one included and that could do pretty much everything you'd see in most pages) but because it was hard to have and maintain the necessary hardware and internet connection.
This still exists and is still an issue today if you want the full ownership down to running your own server. But if you do not care about running your own server and you are fine with shared hosting (which existed even in the 90s, see geocities) or a VPS, then outside of a basic setup you do not need to be much of a technical user (and many hosting and VPS providers have tools to do that setup for you, often for free). For the slightly more technical users, there are tools like Publii (stupid name, but the tool works) that can do mostly full WYSIWYG site editing, management, syncing, etc.
And a dedicated native client? From a user's perspective there is nothing to win here, they already have a browser (and the less technical users are confused by even that), why would they run another browser that wont even work with the majority of the content they want to access?
Really, these are not practical solutions for practical problems. That doesn't mean you shouldn't try to make something like this, but they'll just be toys for fun, not real solutions to real problems and if you expect them to be anything like that you'd be disappointed.
After all Gopher, for example, exists and can be targeted and used, but all of its users are using it for fun and because they can, not because they expect it to compete with the web (well, outside of edgy "the web sux, gopher is the future" comments that are at the same level as "M$ suxx0rz, linux rulez" you'd see not so long ago).
Re: Forking HTML into a static language doesn't make sense
#9HTML doesn't need to be simplified to reign in the complexity.
Rather, it needs to be completed as a hypertext, so that people can build complete software systems using (only or mostly) that language.
See the htmx examples page for stuff that should be doable in plain HTML:
The fact that only anchor and forms, only clicks and submits, only GET and POST and only full page replacement is available in vanilla HTML is the core issue. If HTML had htmx-like functionality you would see far less pressure for large, complex front end frameworks, and it would be completely within the original REST-ful web model[1] that Roy Fielding described.
[1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
Re: Forking HTML into a static language doesn't make sense
#10It does make sense from the point of view of someone embedding HTML as a markup language, for users to edit documents online on a shared domain, and for tooling to be designed alongside these constraints.
As it is, every piece of tooling has to define its own arbitrarily limited subset or an unlimited set of features (and associated attack surface).