3 ms·

> When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, ofte

> When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences. I almost wished we still lived in this world, where the web pages provides the structure and data, and I as the user get to decide how I want to consume it. I think trying to cram web applications into the same model as distributed, hyperlinked documents was fundamentally a mistake. If a browser was just about rendering html, a significant amount of complexity would have disappeared, and you would have a multitude of different browsers, all catering to different preferences in how you wanted to consume html. It is due in large part to the complexity, that we are going towards to monoculture of Chromium/Blink, because only companies with billions of cash in the bank, can afford to dedicate the teams needed to develop a web browser.

nawgz 6y ago
>If a browser was just about rendering html, a significant amount of complexity would have disappeared I don't think this is the right conclusion. I think HTML/rendering engines as described there would have been the thing to disappear. With the smooth user experience of apps & SPAs, a platform with comparable semantics to your nerfed HTML but significantly suped up interactivity features (like not-nerfed HTML) would be all the rage. Plus, I must say, as a web dev, the public-facing web doesn't really do great justice to what you can do with a browser. There's so many internal tools that are super slick, fast loading, bug-free, rendering complex topics like graphs & workflows in attractive yet interactive ways while also supporting client-side validations & computations, all delivered in HTML/CSS/JS. This really isn't a trivial accomplishment, this was driven by the work of many many engineers writing many different tools with increasing complexity, both on the browser and open source sides. The march of this progress wouldn't have stopped just because HTML didn't support it, it would've just replaced HTML.
- kmeisthax 6y ago
  What you're describing existed. It was called plugins. Back in the Old DaysTM, browsers just rendered documents, and if you wanted whiz-bang interactivity features, you ponied up for a copy of Macromedia Flash. Or Director, if you wanted more features and could tolerate it's long plugin download times. Or, if you were more developer-minded, you wrote Java Applets (or, later on, Silverlight apps). Things like Flash didn't ultimately supplant the web, but this is primarily due to three forces: 1. Adobe's insistence on new Player features over security 2. Google's insistence on adding new features to HTML5 via Chrome to support internal business goals 3. Apple's insistence on killing plugins dead to keep the iPhone secure (and cut Adobe out of the developer tools market) The only vestige of plugins that remains are EME implementations (so-called "HTML5 DRM"), but that's purely due to legal reasons. Had HTML not grown to supplant the use cases of plugins, I think it would have stuck around, if only because all those plugins required significant expense to make use of. I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out.
  - bryanrasmussen 6y ago
    >I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out. If they had wanted to do that they could have just supported Deng https://deng.com.br/ https://deng.com.br/
- cmrdporcupine 6y ago
  The way things were in the early days is if you wanted rich interactivity you used Flash, or a Java applet. The rather standard and boring 'web page' still hosted it, but the rich features were to be provided by the applet/plugin. This was both worse and better. Better because it retained the notion of the web as a hypertext system -- not a networked magazine or TV -- worse because what happened in that (usually poorly implemented) little box was its own world outside of the rest of the page. I don't like the present web stack, but I don't have any particular fondness for the mid-90s one I worked on, either.
  - nawgz 6y ago
    To be honest, I perceive the main problems with the present web stack to not be on the consuming developer's end - writing JSX & CSS is honestly a pretty decent representation of what HTML/CSS/JS can actually combine to be. Plus modern JS is a half-decent language, even more so when TypeScript is used. I perceive the main problem to be how hard it is on the implementing developer's side - only megacorps can make functional web browsers. That's a huge problem.
- basch 6y ago
  I absolutely disagree that apps and spas would destroy nerfed HTML, in your example. The web moved in those directions for a multitude of reasons, but user experience isnt necessarily one of them. Server side rendering and a miniscule amount of js can give a great fast experience, and doesn't require the site to use a proprietary layout toolkit. An HTML SSA app, where the user controlled the UI toolkit in browser would be pleasant and easier to develop.
coliveira 6y ago
Yes, in the beginning the idea was that the browser would be responsible for rendering pages nicely. So you could render them in high quality, like current desktop engines, or very quickly in a mobile environment. But of course, publishers didn't like the loss of control. And now we're stuck with a complex tangle of technologies that keep getting out of control.
bioipbiop 6y ago
That’d work great for many sites, but you’d lose a lot of the dynamism that makes the web so great. I think a compromise solution would be to extend the ADA to cover websites, so companies have to produce sites that can be understood by screen readers and other assistive devices. That would more or less give you the outcome you want, but without the need for a prescriptive solution.
sergeykish 6y ago
We still do. Documents web works fine without javascript. There are a lot of browsers - NetSurf, Dillo, console browsers, discontinued open source DOS browsers [3], ed browser [4]. Monoculture stems from the convenience of having both document browser and application platform in one application. > by ViolaWWW, a graphical browser originally written by Pei-Yuan Wei in just four days. The simplest (non graphical) browser I can write in just a few minutes $ gem install sanitize $ curl -s example.com | ruby -rsanitize -ne 'puts Sanitize.clean($_)' Complexity grows from here - collect links to make it interactive, graphical text, images, tables, forms. Add constraints solver, data extraction tools, query RDF, etc. [1] https://www.netsurf-browser.org/ https://www.netsurf-browser.org/ [2] https://www.dillo.org/ https://www.dillo.org/ [3] https://en.wikipedia.org/wiki/Arachne_(web_browser) https://en.wikipedia.org/wiki/Arachne_(web_browser) [4] https://edbrowse.org/ https://edbrowse.org/

nawgz 6y ago

>If a browser was just about rendering html, a significant amount of complexity would have disappeared I don't think this is the right conclusion. I think HTML/rendering engines as described there would have been the thing to disappear. With the smooth user experience of apps & SPAs, a platform with comparable semantics to your nerfed HTML but significantly suped up interactivity features (like not-nerfed HTML) would be all the rage. Plus, I must say, as a web dev, the public-facing web doesn't really do great justice to what you can do with a browser. There's so many internal tools that are super slick, fast loading, bug-free, rendering complex topics like graphs & workflows in attractive yet interactive ways while also supporting client-side validations & computations, all delivered in HTML/CSS/JS. This really isn't a trivial accomplishment, this was driven by the work of many many engineers writing many different tools with increasing complexity, both on the browser and open source sides. The march of this progress wouldn't have stopped just because HTML didn't support it, it would've just replaced HTML.

kmeisthax 6y ago
What you're describing existed. It was called plugins. Back in the Old DaysTM, browsers just rendered documents, and if you wanted whiz-bang interactivity features, you ponied up for a copy of Macromedia Flash. Or Director, if you wanted more features and could tolerate it's long plugin download times. Or, if you were more developer-minded, you wrote Java Applets (or, later on, Silverlight apps). Things like Flash didn't ultimately supplant the web, but this is primarily due to three forces: 1. Adobe's insistence on new Player features over security 2. Google's insistence on adding new features to HTML5 via Chrome to support internal business goals 3. Apple's insistence on killing plugins dead to keep the iPhone secure (and cut Adobe out of the developer tools market) The only vestige of plugins that remains are EME implementations (so-called "HTML5 DRM"), but that's purely due to legal reasons. Had HTML not grown to supplant the use cases of plugins, I think it would have stuck around, if only because all those plugins required significant expense to make use of. I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out.
- bryanrasmussen 6y ago
  >I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out. If they had wanted to do that they could have just supported Deng https://deng.com.br/ https://deng.com.br/
cmrdporcupine 6y ago
The way things were in the early days is if you wanted rich interactivity you used Flash, or a Java applet. The rather standard and boring 'web page' still hosted it, but the rich features were to be provided by the applet/plugin. This was both worse and better. Better because it retained the notion of the web as a hypertext system -- not a networked magazine or TV -- worse because what happened in that (usually poorly implemented) little box was its own world outside of the rest of the page. I don't like the present web stack, but I don't have any particular fondness for the mid-90s one I worked on, either.
- nawgz 6y ago
  To be honest, I perceive the main problems with the present web stack to not be on the consuming developer's end - writing JSX & CSS is honestly a pretty decent representation of what HTML/CSS/JS can actually combine to be. Plus modern JS is a half-decent language, even more so when TypeScript is used. I perceive the main problem to be how hard it is on the implementing developer's side - only megacorps can make functional web browsers. That's a huge problem.
basch 6y ago
I absolutely disagree that apps and spas would destroy nerfed HTML, in your example. The web moved in those directions for a multitude of reasons, but user experience isnt necessarily one of them. Server side rendering and a miniscule amount of js can give a great fast experience, and doesn't require the site to use a proprietary layout toolkit. An HTML SSA app, where the user controlled the UI toolkit in browser would be pleasant and easier to develop.

coliveira 6y ago

Yes, in the beginning the idea was that the browser would be responsible for rendering pages nicely. So you could render them in high quality, like current desktop engines, or very quickly in a mobile environment. But of course, publishers didn't like the loss of control. And now we're stuck with a complex tangle of technologies that keep getting out of control.

bioipbiop 6y ago

That’d work great for many sites, but you’d lose a lot of the dynamism that makes the web so great. I think a compromise solution would be to extend the ADA to cover websites, so companies have to produce sites that can be understood by screen readers and other assistive devices. That would more or less give you the outcome you want, but without the need for a prescriptive solution.

sergeykish 6y ago

We still do. Documents web works fine without javascript. There are a lot of browsers - NetSurf, Dillo, console browsers, discontinued open source DOS browsers [3], ed browser [4]. Monoculture stems from the convenience of having both document browser and application platform in one application. > by ViolaWWW, a graphical browser originally written by Pei-Yuan Wei in just four days. The simplest (non graphical) browser I can write in just a few minutes $ gem install sanitize $ curl -s example.com | ruby -rsanitize -ne 'puts Sanitize.clean($_)' Complexity grows from here - collect links to make it interactive, graphical text, images, tables, forms. Add constraints solver, data extraction tools, query RDF, etc. [1] https://www.netsurf-browser.org/ https://www.netsurf-browser.org/ [2] https://www.dillo.org/ https://www.dillo.org/ [3] https://en.wikipedia.org/wiki/Arachne_(web_browser) https://en.wikipedia.org/wiki/Arachne_(web_browser) [4] https://edbrowse.org/ https://edbrowse.org/