> 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.
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.