3 ms·

Forking HTML might not make sense indeed, but I think this post doesn't make a compelling point as to why or why not.

MaxBarraclough 6y ago
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/ 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 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 https://gemini.circumlunar.space/docs/faq.html
- enumjorge 6y ago
  I don’t understand your first point. As you state yourself, there’s already alternative formats for minimal websites. Current HTML can already do simple, content-only documents. But developers aren’t using those approaches in significant numbers. The existence of these options is not enough to solve the problem otherwise it’d be considered solved. You still need to convince devs to create content for it, which goes back to the authors original point.
  - MaxBarraclough 6y ago
    I'll rephrase what I think you're saying, as I think it's a valid point: Given that we already have the ability to make lightweight HTML-based web-pages, and we also already have a variety of lightweight alternative markup languages to choose from, what's the point of picking one particular subset of HTML and giving it a brand-name? The real goal should be to encourage web developers to make better, more lightweight websites, and/or to encourage use of lightweight alternative markup technologies (to better support very simple browser solutions). Again I think it's a fair point. Another related point: the Gemini project seems to be capable of automatic conversion to HTML. Any such project should make this ability a priority. If you then go ahead and use that, you get an HTML subset 'for free', as the generated HTML files will be lightweight and use few HTML features. We do this today with Markdown. HackerNews won't let me generate a <blink> tag, but we're allowed <i> tags.
jillesvangurp 6y ago
If you step back a little what we have today is a combination of a common browser implementations (aka. the DOM tree + render logic) and bunch of standardized parsing and interpretation logic that maps textual versions of CSS and HTML to this. 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?
- tannhaeuser 6y ago
  > 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. If it is so hard to layer a coherent and not laughably overcomplicated runtime on top of a document viewer in 20 years, then it follows that it probably wasn't such a good idea to begin with. Unless you're hellbent to freeride on the web's success, and ruining it in the process. At which point we're trying to solve an economic problem (someone else's) via a technical solution. To get a sense how far of the mark browsers still are, you only have to look into the problem of rich text editing on browsers, which is a natural step up from pure text browsing, and something the first browser did already. Today, this is only barely possible thanks to a couple rich text editor projects who made heroic efforts to work out browser quirks (with contenteditable such that the browser's spellchecking can be leveraged, or alternatively using Canvas/WebGl, essentially developing a browser-in-browser). In a situation where browser vendors struggle to keep up, adding additional tech such as WASM is the last thing you want to do. When and if WASM gets even basic language infrastructure such as gc, DOM or WebGl bindings, or anything even mildly interesting, then it'll immediately become another maintenance problem. And as you said yourself, at best WASM can help port apps over to a browser. It's however not clear what the purpose of that exercise should be when said apps run just fine outside the browser. I'd say if there were indeed so many apps waiting to be ported over to running in the browser, then there have been sufficiently sophisticated transpilers for like 15 years now (emscripten, gwt, many others), so I'm not buying that as an argument to make browsers even more complex.

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/ 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 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 https://gemini.circumlunar.space/docs/faq.html

enumjorge 6y ago
I don’t understand your first point. As you state yourself, there’s already alternative formats for minimal websites. Current HTML can already do simple, content-only documents. But developers aren’t using those approaches in significant numbers. The existence of these options is not enough to solve the problem otherwise it’d be considered solved. You still need to convince devs to create content for it, which goes back to the authors original point.
- MaxBarraclough 6y ago
  I'll rephrase what I think you're saying, as I think it's a valid point: Given that we already have the ability to make lightweight HTML-based web-pages, and we also already have a variety of lightweight alternative markup languages to choose from, what's the point of picking one particular subset of HTML and giving it a brand-name? The real goal should be to encourage web developers to make better, more lightweight websites, and/or to encourage use of lightweight alternative markup technologies (to better support very simple browser solutions). Again I think it's a fair point. Another related point: the Gemini project seems to be capable of automatic conversion to HTML. Any such project should make this ability a priority. If you then go ahead and use that, you get an HTML subset 'for free', as the generated HTML files will be lightweight and use few HTML features. We do this today with Markdown. HackerNews won't let me generate a <blink> tag, but we're allowed <i> tags.

jillesvangurp 6y ago

If you step back a little what we have today is a combination of a common browser implementations (aka. the DOM tree + render logic) and bunch of standardized parsing and interpretation logic that maps textual versions of CSS and HTML to this. 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?

tannhaeuser 6y ago
> 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. If it is so hard to layer a coherent and not laughably overcomplicated runtime on top of a document viewer in 20 years, then it follows that it probably wasn't such a good idea to begin with. Unless you're hellbent to freeride on the web's success, and ruining it in the process. At which point we're trying to solve an economic problem (someone else's) via a technical solution. To get a sense how far of the mark browsers still are, you only have to look into the problem of rich text editing on browsers, which is a natural step up from pure text browsing, and something the first browser did already. Today, this is only barely possible thanks to a couple rich text editor projects who made heroic efforts to work out browser quirks (with contenteditable such that the browser's spellchecking can be leveraged, or alternatively using Canvas/WebGl, essentially developing a browser-in-browser). In a situation where browser vendors struggle to keep up, adding additional tech such as WASM is the last thing you want to do. When and if WASM gets even basic language infrastructure such as gc, DOM or WebGl bindings, or anything even mildly interesting, then it'll immediately become another maintenance problem. And as you said yourself, at best WASM can help port apps over to a browser. It's however not clear what the purpose of that exercise should be when said apps run just fine outside the browser. I'd say if there were indeed so many apps waiting to be ported over to running in the browser, then there have been sufficiently sophisticated transpilers for like 15 years now (emscripten, gwt, many others), so I'm not buying that as an argument to make browsers even more complex.