Re:Maintaining an Independent Browser Is Expensive
by roca on Sunday December 03, 2017 @04:01PM
(#15839567)
The alternative to a "living document" is "we have a bunch of updates and errata, and you're going to have to piece together the current version yourself from many sources".
If you really need an unchanging version, download some version and use that.
Re:Maintaining an Independent Browser Is Expensive
by userbinator on Sunday December 03, 2017 @05:24PM
(#15840003)
No, the alternative is a versioned document.
Re:Maintaining an Independent Browser Is Expensive
by roca on Sunday December 03, 2017 @07:12PM
(#15840478)
These documents are versioned in VCS. The core issue is that either you update the master document every time you have a fix, or you don't.
If you do, it's a living standard.
If you don't, then people have to cobble together the latest version from various sources.
Re:Maintaining an Independent Browser Is Expensive
by zaarn on Monday December 04, 2017 @03:07AM
(#15842375)
Or alternatively, follow a strict release cycle, ie, once a year and publish that. Have all standards follow this cycle.
The choices aren't "commit everything to master" or "commit everything into various versions".
A strict release cycle also prevents having some hype extension which only a few people actually use since it takes more effort and dedication to get stuff into the standards.
Yeah, it's enough to be infuriating. I've recently been thinking about what it would take to implement a lynx-like browser that had a better understanding of layout and could deal with the modern web.
Hurdle number one is that there's no "Web standard", but rather a great many interrelated standards. At a bare minimum, you need HTTP K₁, SSL/TLS K₂, HTML K₃, XHTML, DOM N, CSS K₄, and ECMAScript K₅. Several of those standards are actually multiple standards, so you'll have to do some digging. That's the easiest hurdle to overcome. Number two is that a few of the standards (including some really fundamental ones like the DOM) are maintained as "living documents", making them moving targets; even the—uh—"dead" documents are subject to speedy revisions (for example, there have been 3 new ECMAScript revisions in the last 3 years). Number three is all the up-and-coming experimental stuff that isn't standardized yet, but if at least one browser supports something, some website somewhere is already using it. Between two and three, you'll need to keep a finger on the rapid pulse of the Web. And on top of all that, you have to support legacy bullshit, deal with malformed documents, and be ever hyper-aware of security threats.
Allowing for off-the-shelf components like libcurl and duktape, I'm sure it's still doable by a single person, but it's a lot of work (much of it frustrating).