On stability

I can think of two reasons for pace browsers are developed at. The first is because it is a monumental task, and when you are undertaking a monumental task break it down in to small bits and release early, release often, otherwise you will be overwhelmed. This is because, as standards go, those published by W3 are real pricks. We have enormous teams of programmers implementing them. As I said they haven't changed much in 12 years, yet a seemingly simple thing like rendering ACID3 correctly is a huge challenge. This is what happens when you publish the standard before writing the code. The IETF's policy of producing working code then publishing the standard is how it should be done. The difficulty in implementing a fully compliant HTML, CSS, and SVG are great examples of why it should be done that way.

The second reason is to do with marketing. I used to use, and still occasionally use Firefox 1.0.1. It has UI bugs, it crashes, and it renders things badly. But it was fast, and if they had just fixed those bugs I would be happy running it today. (Although maybe not for much longer, given the advent of HTML 5.) Fixing those bugs didn't require millions of lines of code to change every few months. What does require a new release every few months is a mindshare competition. (Why do you think Ubuntu does it?) What triggers most of those millions of lines of changes is new eye candy - something like rearranging the tabs and title bar, or the introduction of an "awesome bar".

So it is a combination of those two things - the size of the task means implementing a web browser will take 100's if not 1000's of man years, and that means a steady stream of releases as you do it. This is not unlike we see with the kernel or any other large project release. We know Debian can handle that. But them you mix those necessary changes with avalanche of bubble and froth created by a mind share competition - ie change for no reason than it generates publicity, and you become incompatible with a distribution that values stability over most over things.

I disagree. The de facto standards trail the real ones by a large margin.

That is because the de facto standards are to a large extent determined by the oldest browser in use. Until very recently IE 6, which was released in 2001, and it didn't comply with the existing standards in force back then. Google and Facebook only just stopped supporting it.

This "the browsers must change because the web is changing" thing is a complete furphy. Certainly the web is changing. But that is because people are writing millions of millions of lines of javascript as they figure out how to use this "new" platform. But just because the stuff we build on top of the underlying platform changing at a dizzying rate doesn't mean the platform itself must be changing. On the contrary, it hasn't, until now with HTML5. Inventing new ways to do web pages no more depends on HTML/javascript change than the advancement of the linux kernel depends on gcc changing.

"Handling things correctly" doesn't mean "test with every obscure Linux distribution", or even "test with the top N distributions". It means "make sure it builds in whatever reasonably up-to-date distribution the developers run, handle shared library versioning sanely, document the list of build dependencies, let Linux distributions package it, and work with them when they report bugs to you".