Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>
You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site.
Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.
Everything is unrealistic until it becomes real. I naturally tend towards cynicism sometimes, but I try to practice dreaming a little. I find I'm happier when I try to imagine the world as it could be and what I can do to push it that direction.
True, general web layout is a hard problem. But there are a lot of knobs to turn. What if we removed CSS layout altogether, and only allowed linear pages, a la reader mode? That's a big tradeoff, but maybe it would work. If that's too much, maybe only allowing flexbox would be enough. As for editing, at that point you're making a web app.
> As for editing, at that point you're making a web app.
Are you getting rid of Web forms now? Also, remember that at the very beginning Berners-Lee's WorldWideWeb browser supported HTML editing, so it's definitely part of some vision of the "good old days".
Yes, if you cut down or eliminate CSS, or just redesign it, you could build a faster renderer.
But these questions point to one of major defects of the "cut-down Web" vision: lots of people have a limited set of Web features that they like, but they tend not to agree on what that set is. You like flexbox. Some people really like grid. Some people really need ruby, or floats, or columns, or editing, or vertical breaking (pagination). Pretty soon you've got something nearly as complicated as real CSS.
> But these questions point to one of major defects of the "cut-down Web" vision: lots of people have a limited set of Web features that they like, but they tend not to agree on what that set is.
Democracy to the rescue:
1. Start a FLOSS mailing list thread to get as much input as possible on the best starting point for this reduced set of functionality. Gopher, resurrecting Xanadu, revisiting Hypercard, and so on. Let the conversation flow.
2. Invite the people who chose Firefox Reader View to private gitlab instance and get to work.
I think getting rid of editability would be great. The whole point is a minimal browser. I don't really want to cut down the web. I want to start from scratch but in a manner compatible with our current JavaScript VMs.
I agree but a lot of the pre-flexbox stuff in CSS is just plain crap. However, I don't think removing obsolete CSS constructs will make anything faster or better because you're not forced to use them.
If you want to push the world in your direction, join a browser company. You may or may not be able to push them in your direction, but you'll at least understand the problem space a lot better to see where it's worth pushing.
You're talking about this from a value-proposition point of view. Whether something is worth doing doesn't depend only on the final value. It also depends on the amount of effort to do the thing. If the amount of effort is tiny, then it's probably best to do the thing and see what happens.
I share your dream, brother. This is why I design for every browser, with progressive enhancement.
The browser you describe already exists, it's one with JS disabled, and you ignore the sites which don't work without it. This is how I browse every day.
I don't feel like I'm missing much.
I enable JS for reddit because I have to mod things, but I find myself visiting that site less and less now. HN works. Facebook works (good enough.) Gmail works. Google Search and DDG work. GitHub... meh.
I can already see my own apps work without Javascript support. I'll convert video streams into permanently loading gifs and add 2 million invisible pixel sized form buttons arranged in a grid on top of the entire website so that I can send pixel coordinates to my server. Oh, and there will be a virtual keyboard made out of a form element so that there is no need to listen to keyboard events. There will be a huge spike in users who disable Javascript and they will flood my servers until the site crashes from the massive load.
I was thinking more of the simplified HTML/CSS specification for AMP. Or at least that what I thought AMP was. I did a quick google search, first link was to the Google Amp guidelines, which has a link to ampproject.org. I can't get there, the browser won't let me because something is wrong with their SSL certificate (the cert's common name is firebaseapp.com, and it is serving up on amlpproject.org).
