It is untrue. You can write a plain HTML (even without CSS) and it will work OK.
> Webpage size growth is outpacing it all.
It is true, unfortunately. They waste too much space by adding too much extra pictures, CSS, JavaScripts, videos, advertising, etc. You should not need all of that stuff.
> Not only is it nearly impossible to build a new browser from scratch, once you have one the ongoing cost of keeping up with standards requires a full team of experts.
Yes, this is the real problem. However, some of the standards simply should not be implemented, and some should be implemented differently than what the standards say, to give advanced end users better controls and improve efficiency and many other things.
> We hope that all this innovation is for the user, but often it isn’t.
That is true, it isn't. To make it for the user, design the software for advanced users who are assumed to know what they are doing and that the end user customizes everything. Make documents without CSS; the end user can specify what colours/fonts they want. Make raw data files available; the end user might have programs to view and query them (possibly using SQLite).
> There is the “document web”, like blogs, news, Wikipedia, Twitter, Facebook.
I do not use Facebook, but I can comment about the others. There is NNTP, too. Wikipedia (and MediaWiki in general; not only Wikipedia) uses a lot of JavaScripts and CSS too; you can add your own, but removing the existing ones and replacing by your own will be difficult. If you want to replace the audio/video player with your own, can you do it? What is needing is making actual proper HTML, or EncapsulatedHyperEncyclopedia format, perhaps.
> Basically CSS, which we now think of as a way for designers to add brand identity and tweak pixel-perfect details, was instead mostly a way of making plain documents readable and letting the readers of those documents customize how they looked.
I still often disable CSS, but sometimes result in big icons and other things still wasting space. Maybe if disabling CSS would support ARIA and other things might to actually make an improvement.
One idea that I have is that if your document only uses classless CSS and that a web browser that supports the semantic HTML commands (and not the presentational commands) should display it suitably, specify a feature="usercss" attribute in the and/or element that specifies the stylesheets, so that a web browser can understand to use it. This way, it will be up to the end user to set their own styles as they want to do and can effectively use it in favour of the author's one without breaking it.
> Though it’s going to be a rough ride in the current web which has basically thrown away semantic HTML as an idea.
Semantic HTML can be a good idea, and still is sometimes used, even if it is often ignored (and sometimes not implemented in the client side, too) in favour of bad stuff instead.
> Rule #3 is make it better for everyone. There should be a perk for everyone in the ecosystem: people making pages, people reading them, and people making the technology for them to be readable.
Yes, it is true. For people reading pages better, do not have any styles specified in the document. Let the end user to specify their own colours/fonts/etc, and different implementations can render them as appropriate for the interface in use.
> I think this combination would bring speed back, in a huge way. You could get a page on the screen in a fraction of the time of the web. The memory consumption could be tiny. It would be incredibly accessible, by default. You could make great-looking default stylesheets and share alternative user stylesheets. With dramatically limited scope, you could port it to all kinds of devices.
Yes, these are the greater benefits.
> What could aggregation look like? If web pages were more like documents than applications, we wouldn’t need RSS - websites would have an index that points to documents and a ‘reader’ could aggregate actual webpages by default.
Yes, that will work, although you may want metadata fields to be available. (An implementation might then allow end users to specify SQL to query them, or other things are possible.)
> We could link between the webs by using something like dat’s well-known file, or using the Accept header to create a browser that can accept HTML but prefers lightweight pages.
The documentation for dat's well-known file does not work (it just tries to redirect).
Using the Accept header is possible, but has its own issues. You might need to list one hundred different file formats to indicate all of them, you might want to download an arbitrary file regardless of Accept headers, etc.
> Application web 2.0
There are problems with the containers, web applications, etc, which is that they do not have the powers of UNIX, TRON, etc.
About separation of application web vs document web, I think that they should not be joined too closely together nor separately too far apart.
I have may own design which is VM3 (the name might or might not change in future), and we can then see what we will come up with. (It could be used with static document views only, executable codes with command-line or GUI or other interfaces, etc. The design is meant to improve portability and security, as well as user controls and capabilities.)