Post
But as I've already mentioned in other threads, the #GeminiProtocol approach IMO throws away the baby with the bathwater. Many of the web formats and technologies are actually extremely useful even for the “web of documents”: the problem isn't with #HTML, #CSS, #XML, #XSLT, #SVG or even #JavaScript, the problem is that browsers have been catering exclusively to the “web of apps” instead of the “web of documents”. We *can* keep that tech *and* the “web of documents”.
18/
Classic #OperaBrowser had an interesting approach: since it couldn't guarantee, despite all efforts, perfect compatibility with websites that weren't designed around web standards but “for specific browsers”, it provided a menu option to open in a different browser any page you were in. I don't think I've seen such a feature in any other browser, but I think it's actually the simplest solution to the diverging paths for the two webs.
19/
(This is actually a feature that all browsers should have, regardless of the “apps vs documents” thing, and while I can understand why the major ones won't, I hope to see all others adopt it.)
20/
If we accept that the “web of apps” and “web of documents” are two separate things, and that the development and maintenance of the browsers for the “web of apps” is essentially left in corporate hands, what is left is the question: how expensive is it to develop and maintain the browsers for the “web of documents” ?
And I suspect that the answer is “much less” (than the “web of apps”).
21/
For starters, most of what the #WHATWG is working on is largely irrelevant for the “web of documents”. This means largely no development efforts to “run after the latest revision of the spec”. I would expect most of the work to be of the maintenance kind (fixing bugs, security issues, and the like), which is sadly the kind of brutal, unglamorous work nobody wants to do.
22/
A space for Bonfire maintainers and contributors to communicate
