> Now suppose that in about five weeks, Google push a breaking change in the new release of Chrome
No, I refuse to swallow this particular strawman that you've been using throughout the thread.
I'll elaborate. Web development projects should be undertaken with reference to the current state of support across browsers for current and emerging standards, with the expectation that such support will improve over time. Basing your tests on the rendering characteristics of a single browser at a single point in time is simply wrong-headed. So this 'breaking change' idea is not just wrong but incoherent.
Obviously 'breaking changes' can happen in the context of browser UI but (a) that has nothing to do with web development and (b) rolling release schedules are actually better at catching those problems than epoch-making version releases.
> Web development projects should be undertaken with reference to the current state of support across browsers for current and emerging standards, with the expectation that such support will improve over time.
Says who?
If you're developing a major project, for a major client, for serious money, then there will be formal acceptance tests, and if the product you build doesn't pass those tests, you don't get some or all of the money until it does. What kind of professional web development shop is going to make that kind of commitment when the tests themselves aren't pinned down, or to make any legally binding commitment that their finished product will work properly with software that is beyond their control and not fully specified? You can't even defend this position on the basis of Agile development practices, because a six week cycle is still too short to get through a full round of development, a full set of testing at the various levels required, and final approvals, before the goalposts move again. You don't seem to acknowledge this scenario at all, but outside of relatively small projects it is the norm.
As several of us have observed elsewhere in the discussion, the major problem with making this kind of open-ended commitment when the target platform isn't known yet is that sometimes support doesn't improve over time. We have even given direct examples, such as Google's decision to kill H.264 support in Chrome.
I didn't say not to test. I said not to test only on a single browser version.
> Says who?
Do you really need a list?
> when the tests themselves aren't pinned down
Test for compliance with the standard, not compatibility with the engine. If not enough engines support a feature for which the standard is still emerging don't use it.
> We have even given direct examples, such as Google's decision to kill H.264 support in Chrome.
Your examples don't hold water. No specific codec support should be assumed at this point because it's not standardised.
No, I refuse to swallow this particular strawman that you've been using throughout the thread.
I'll elaborate. Web development projects should be undertaken with reference to the current state of support across browsers for current and emerging standards, with the expectation that such support will improve over time. Basing your tests on the rendering characteristics of a single browser at a single point in time is simply wrong-headed. So this 'breaking change' idea is not just wrong but incoherent.
Obviously 'breaking changes' can happen in the context of browser UI but (a) that has nothing to do with web development and (b) rolling release schedules are actually better at catching those problems than epoch-making version releases.