First off, let me say that I too shared the reservations many of you are expressing. In fact, it took me nearly two months to realize that this was the best way to move the web forward while preserving our investments thus far.
In response to a few questions/statements:
bq. I am fearful of the possibility that companies stop thinking about how to offer improved accessibility, usability, and functionality buy building a site that is IE7 compliant and then leaving it for the next 10 years, bugs and all.
I think that’s a pretty good trade-off for adding a standards compliant @meta@ element to documents.
bq. I can’t see Opera (or whoever) in 5 years time delivering an Opera 15 with 5 different rendering engines for versions from 10 to 14!
I am not a browser vendor nor have I ever made a browser, so I don’t know what percentage of browser code is specifically devoted to rendering and scripting support, but I can say that it would seem reasonable to me that browsers may retire certain rendering modes as time passes. Broswers will have the ability to read the rendering modes of pages and report on that. If, over time, certain rendering modes start to take up a smaller and smaller piece of the content pie, it may be justifiable to end support for them. But, again, I’m not a browser maker.
On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem. That said, I am as concerned as anyone with code bloat and hope that knowing these engines will need to exist well into the future will provide the impetus needed to keep developers honest and their code clean.
bq. There’s a big case of weasel words in this article. While it’s fair to say that IE8 in standards mode renders Acid2 correctly, that’s completely not equivalent to “˜passing Acid2’. Passing Acid2 requires the browser to render http://www.webstandards.org/files/acid2/test.html correctly, and I don’t see any meta tags on there.
An astute observation, “Robyn”:http://www.alistapart.com/comments/beyonddoctype?page=1#8; it’s true that the ACID2 test doesn’t have the @meta@ required to trigger IE8 to use the latest rendering mode, so IE8 does not _technically_ pass the test. But it is also possible to use an HTTP header to accomplish the same thing as the @meta@ element. So, with the X-UA-Compatible HTTP header applied, IE8 would, from what I understand, pass the ACID2 test.
bq. Can I ask if you were paid by Microsoft for this effort,
and if so how much?
As “Jeffrey said”:http://www.alistapart.com/comments/beyonddoctype?page=2#20, I received no money for my work on this project. In fact, the one time I did fly out to Microsoft for a discussion of IE8, I paid my own way.
bq. I am sorry, but this can only be described as madness. We are talking about browser sniffing and code forking here, are we not?
Actually, no. This implies no code forking whatsoever. Version targeting simply lets browsers know what browser version the site was built against. It does not require or endorse browser sniffing or code forking. Nothing we have been doing, to date, would change, except we would have to include the @meta@ element to tell IE (and perhaps, eventually, other browsers) we are targeting a particular version of that browser. We will be able to continue using progressive enhancement techniques as we have been for the last few years, the only difference being that we will be able to introduce support for new browser versions on our timetable instead of the browser vendor’s.