Unfortunately they likely won't due to IE being big in the enterprise. This is also why they tend to not add features in between revs, just bug fixes. And even then they won't fix a standards comformance bug unless there's a security issue.
Enterprise users want to be able to say, "Use IE9 to access your expense reports, period". They don't want it to be "Use IE9.0.1.2.1.a or above" or "IE9 shipped before 10/1/2011".
Pushback from the enterprise is probably driving this more than anything else.
They could go to a model where they have a consumer and enterprise branch. And the enterprise branch syns up with the consumer branch on major releases. But that starts to sound a little chaotic (but I think doable).
> Enterprise users want to be able to say, "Use IE9 to access your expense reports, period".
Every time people bring this up they make it sound like it's a legitimate requirement. It's not, and the cost of supporting a given browser's rolling release schedule in-house at these companies is miniscule compared to the global cost to the web development industry and user productivity of having to support three (possibly four) different versions of IE at any one time.
> the cost of supporting a given browser's rolling release schedule in-house at these companies is miniscule compared to the global cost to the web development industry and user productivity of having to support three (possibly four) different versions of IE at any one time.
That's a mighty bold claim to make without any supporting data, given that the maths is so heavily stacked against you.
Suppose a 5,000 person company standardised on Chrome tomorrow and built their key in-house IT systems to support it, as many have with IE over the years. Now suppose that in about five weeks, Google push a breaking change in the new release of Chrome, that takes out some of the organisation's key intranet functionality. What would that company do?
Think quickly, because for every hour that key system is down and all the staff are stopped from working, the company could have hired an extra web developer for an entire year.
> 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.
Think quickly, because for every hour that key system is down and all the staff are stopped from working, the company could have hired an extra web developer for an entire year.
and the cost of supporting a given browser's rolling release schedule in-house at these companies is miniscule compared to the global cost to the web development industry
I hate to break this to you, but nobody cares about this amorphous global cost to the web dev industry. It's a cost that isn't accounted for and accrues in a uniform way that makes it inactionable.
If MS were to start telling the Fortune 500 companies that it was going to start screwing them over and not supporting old browsers -- IBM would immediately step in and start doing it. MS would lose most of their revenue (guess what, web devs don't generate much revenue for MS) and IBM would become the fastest growing company in the world.
It's just stupid to PO paying customers to help people who whine, but pay nothing.
You're missing the point (I hate to break it to you). The F500 and Microsoft can do as they please, but stop expecting the web dev community to take seriously this claim that they need to standardise on version X of a browser. We don't care anymore.
Who is "we" here? Am I talking to the official spokesperson for all non-enterprise web devs? Last time I checked Facebook, Google, CNN, NYTimes, and Twitter all worked with IE.
When webpages that people actually care about break in IE then I'll believe you. Until then, I think people will go where the money is. Now maybe you won't support IE. That's your choice, but I suspect you're not the director for webdev at Facebook.
In fact, if you let me know what your sites are, I can add them to my blacklist to avoid us both the trouble of your sites showing up in my Google search since they may take down my browser at any point in the future.
> Am I talking to the official spokesperson for all non-enterprise web devs?
No. Is there a reason why you would ask such a ridiculous question?
> Last time I checked Facebook, Google, CNN, NYTimes, and Twitter all worked with IE.
Again, that doesn't affect my point which is: that the compatibility restrictions are arbitrary, unnecessary and completely unworthy of sympathy from the community.
> let me know what your sites are, I can add them to my blacklist
Then you won't be getting many contracts from large organisations, and people who work at large organisations won't be using anything public that you develop on their lunch break. If that doesn't matter to you, that's OK, to each his own. But it does matter to a very large group of people in the web development community who make their living building professional sites for professional clients.
> Then you won't be getting many contracts from large organisations
I would appreciate it if you and the other guy would stop making this personal, but I'm not expecting much.
Nowhere did I talk about development practices. What I talked about was the justification often held out to web developers that such-and-such state of affairs is absolutely and perpetually necessary. My professional conduct has nothing to do with that, thank you very much.
I'm not sure what you're reading into my posts that you consider "making this personal", nor which person or people you think I'm going after, but I promise you've misunderstood my meaning if that's the impression you've got.
Enterprise users want to be able to say, "Use IE9 to access your expense reports, period". They don't want it to be "Use IE9.0.1.2.1.a or above" or "IE9 shipped before 10/1/2011".
Pushback from the enterprise is probably driving this more than anything else.
They could go to a model where they have a consumer and enterprise branch. And the enterprise branch syns up with the consumer branch on major releases. But that starts to sound a little chaotic (but I think doable).