> Firefox, the WebKit team, and Opera are basically already operating on this model. Team IE isn't.

And for the reasons I have explained elsewhere in this discussion, I think team IE are the only ones who have an approach that can actually work in the long term. A standard isn't a standard if it's constantly changing, and progress at a rate the world can keep up with is more useful than browsers progressing at a much faster rate but actual web pages not progressing at all.

Regardless of which model you think is right, the reality of the situation is that HTML will be changing all the time.

But the subset of HTML that is used on most real sites won't change much at all. It will be too much hassle for casual web sites to keep up, even if they could benefit from any of the new features, which most couldn't because it's still as crazy as it ever was to view the web as a good alternative platform to native apps. The cost/benefit will be dubious for most businesses for similar reasons.

The entire rapid-release-cycle idea is one big overreaction by people who are fed up with the glacial pace of standards development at organisations like the W3C. In a few years, I expect we are all going to be looking back in bemusement, wondering what possessed us to try to advance such a complicated industry without meaningful standards, and wishing we'd just stuck with stable standards all along.

Another possibility is that we will have simply lost interest in the whole affair, because the advancing technologies that help to build more practically useful tools around remote protocols won't be HTML and CSS anyway. For example, a simple delivery mechanism for native apps, along the lines of mobile app stores today, could have ended the current fool's quest to rewrite every serious desktop application on top of poorly suited web technologies, because, leaving the web to do what it does best, present and collect information.