IE8 May Not Pass the Acid2 Test After All 434
dotne writes "CNET has published an article called Acid2, Acid3 and the power of default. The article predicts that IE8 will not pass the Acid2 test after all: '[Another] scenario could be that Microsoft requires Web pages to change the default settings by flagging that they really, really want to be rendered correctly. Web pages already have a way to say this (called doctype switching, which is supported by all browsers), but Microsoft has all but announced that IE8 will support yet another scheme. If the company decides to implement the new scheme, the Acid2 test — and all the other pages that use doctype switching — will not be rendered correctly.' Microsoft's IE8 render modes have been discussed here previously, and they've caused an uproar in the web development community. According to the scheme, authors must put Microsoft-specific <meta> tags into their pages in order for them to be rendered correctly. I doubt Acid2, nor Acid3 will have Microsoft extensions in them."
Page specific tuning (Score:5, Interesting)
Make Acid2 the Default (Score:5, Interesting)
I think we're at the moment when developers want standards, where in the IE4/NS4 war, everyone and their brother was trying to hack-together web pages, and IE did some nice exposition of the DOM via the ID attribute in tags, which accomodated less-skilled programmers. Now that the baseline-developer's skills are improved, and the IDEs out there are actually pretty decent (e.g. Not FrontPage, Not MS Word) I'd say the time is right.
While the Acid2 test is niceity, what I'd really love to see is a standard plugin model shared by FF and IE. It has been a while, but I always thought the "EMBED" inside of an "OBJECT" tag was lame. I don't like ActiveX but I get in intranet environments where it can be useful, where the code should be "trusted" and "signed", where you're essentially using a browser to "publish" applications that should probably be desktop applets, or use a native HTML (AJAX?) interface rather than "VB applet on a webpage." That being said, we need an out in the wild, "safe" plugin/viewer model.
Re:Page specific tuning (Score:5, Interesting)
Note, though, that he doesn't say that explicitly, and you shouldn't assume that he will. It's my own conclusion, and you should draw your own, etc...
Serious question: (Score:2, Interesting)
Re:It's the most logical decision (Score:3, Interesting)
Re:It's the most logical decision (Score:3, Interesting)
Two pages for IE (Score:2, Interesting)
Now you'll have to create TWO pages... one for IE7 and one for IE8.
Wanna bet people say something along the lines of: Why develope for IE8 when it will render my IE7 page perfectly BY DEFAULT.
I think they have it backwards... add the meta tag if you want the browser to go into "broken IE" mode.
Re:Make Acid2 the Default (Score:5, Interesting)
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4"
What is there to not like in this? It's a simple, elegant and practical solution to this very real problem. Sure, it could have arrived earlier, but better later than never.
I'll tell you what's amazing (Score:2, Interesting)
All of this whining about Microsoft's approach to standards implementation on IE 8 sounds like it is coming from a bunch of academic eggheads who've not held a job in web development in their lives. I, like most web developers that have a job have been using user_agent sniffs for some time to make sure that IE 6's wonky non-standard approach is accounted for. I suspect that many have done the same as I - look for "MSIE" in the string, make the adjustments for MS's buggy implementation, and call it a day. So if Microsoft suddenly goes compliant every one of those pages will break. The only reason I didn't face a mass break on IE 7 is IE 7 goes to quirks mode when the doctype is missing (and it's missing on most all my legacy pages. My newer pages have them and I had to fix 12 of them for IE 7's changes).
Microsoft doesn't follow standards. I don't know about some of you nerds but I've got some 300 sites that have code that will break if MS decides to follow the standard. I don't personally like the idea of going in and rewriting the drive code for those pages again. Yes, it would have been better if Microsoft had followed the standard in the first place but they didn't and as far as I can tell this is about the only way out of the problem they've created for them.
Now I know that in the fantasy world of some the moment a new version of IE comes out the pages written to the bad standard MS foisted on us dissappear - but that isn't the case. Hell, there are pages out there still written for Netscape 4. Microsoft has the unenviable position of striking a balance between the needs of the development community - one standard to rule them all - and the clients of those developers - "I don't give a damn what you have to do to make it work, just make it work."
I don't know about the rest of you, but if my old clients started coming to me because their pages look like crap in the newest IE the words, "but it's Microsoft's fault - tech blah blah blah blah" they'll won't accept the explanation - because for most of them the explanation involves technical details they don't give a damn about and they pay us to handle for them because we're supposed to be the professionals. At the end of the day the majority of the world doesn't give a flying rat's hindquarters about standards - they simply want the web to work.
Microsoft does a lot of asinine crap that they fully deserve to be taken to task for - but this isn't one instance of it. Breaking pages to make way for the "future" would only further the drive of folks to other browsers.
All of that said, Microsoft has a cleaner solution available to them - change IE 8's http_user_agent string so completely that browser sniffing software will (presumably) feed them the standards compliant page. Personally that's what I do - if you're using IE, Firefox, Safari or Opera I'll adjust for your browser bugs - if not you'd better be able to handle CSS 2.1 strict cause that's what you're gonna get.
Worst... Proposal... Ever! (Score:5, Interesting)
Microsoft claims that the X-UA-Compatible flag is necessary on standards-compatible content to avoid breaking IE-specific content. I call BS.
For years, Microsoft has been telling everyone to put version-specific IE hacks in conditional comments [microsoft.com], in case IE's behavior improves in future versions. Now that they are finally fixing IE, they spring this X-UA-Compatible "solution" on us, punishing those who have been producing standards-compliant content and rewarding the zombies who have been writing IE-specific code. If your site is standards-compliant, you have to do the extra work to tag it as such, and keep that crufty tag around for the foreseeable future!
If you sat down today and wrote a new standards-compliant browser, it would work just fine with almost all the content and web applications out there. Apple did this recently with Safari. Microsoft claims to have done this with IE 8. Safari didn't need any X-UA-Compatible flag. Why should IE 8 need one?
The only reason IE 8 would need the X-UA-Compatible flag is simply because it is IE 8. If their new browser identified itself as, say, "Microsoft Trident VI [wikipedia.org]" instead, things would just work. Microsoft could still call it "Internet Explorer 8" for marketing purposes, but web developers would know that "MS Trident VI" means IE 8, just as "WebKit 4xx" means Safari 2 (or similar browsers) and Gecko means Firefox (or similar browsers).
Dear Microsoft, here's a sane solution for you:
As you see, it is possible to fix IE in a backward compatible way without introducing a X-UA-Compatible flag. The chances of Microsoft taking these steps is almost nil, since it places IE 8 on an even playing field with other standards-compliant browsers. That's why they are proposing X-UA-Compatible -- they can claim to support web standards while knowing that web developers will find it easier to muddle along than to use their stupid flag.
How bout wiping the slate clean? (Score:2, Interesting)
In 5 years, when the old engines are removed leaving just the one way to render a page, ancient stuff written to specification will still work, the only thing is pages that are effectively "broken" will need to be fixed in 5-10 years... if there are any still around.
Re:Hear hear (Score:2, Interesting)
For everyone who uses Doctype, it can be assumed that they're using some kind of html generator, and that generator is already generating two kinds of pages, one for IE and one for w3c compliant browsers.
Just have the web server treat IE8 as a w3c compliant web browser... and have IE8 treat the web page as a w3c compliant/standard page, problem solved. Why would IE8 ever have to render a standards compliant page in a non-standard manner? And in those cases, shouldn't the page indicate that it's an IE7/non-standard page?
Jesus H Christ, folks, this ain't rocket science.
Re:Page specific tuning (Score:3, Interesting)
There exists a perfectly good tag which in essence states "I know what I'm doing; this is the version of HTML I'm using, please render this strictly". This is the DOCTYPE tag.
It turns out that many pages which have the DOCTYPE tag were written by someone who clearly didn't know what they were doing. Thus, they broke because IE6 had a curious definition of what constituted strict rendering.
Microsoft's proposal is an HTTP header which may be embedded with a META tag, the meaning of which is "I know what I'm doing, this is the browser I'm targeting, please render this as per that browser". A mechanism which may make sense if the only browser which has ever existed is IE, and the only thing you need to worry about is different versions of IE, but is completely nonsensical when there are many other browsers which are now garnering enough attention that they're actually getting used and are being accounted for in site development - the only way it can work across the board is if everyone else reverse engineers the rendering model used by every version of IE and re-implements it.
Re:Page specific tuning (Score:4, Interesting)
My current version of Firefox does not pass Acid2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Any browser that follows the standard deserves my admiration. Adding more meta tags where this stuff should be in the doc type is not a correct decision and should be reviled.
Maintenance problem, NOT a solution! (Score:2, Interesting)
What I don't get is why people even bothered with IE 6 "standards mode"?
Microsoft's documentation and documented quirks/workaround all over the web clearly laid out the case for using quirks mode for both IE 5 and 6 and waiting until at least IE 7 came out to implement any sort of "standards mode" rendering shift using the DOCTYPE switch.
Microsoft said quirks mode WOULD NOT CHANGE and that standards mode WOULD CHANGE with new browser versions. It was a NO BRAINER for any (competent) developer wanting their pages not to break with IE 7 or other future IE release to induce quirks mode (IE 5 rendering) in IE 6 using an HTML comment or XML processing instruction before the strict DOCTYPE and then using standards-compliant markup and CSS, with a separate compatibility stylesheet for fixing browser bugs targeted specifically to "lte IE 6" using conditional comments.
People having done this wouldn't have had to even touch the HTML again when/if a new IE browser version came out. The pages would render in standards-compliant mode for all current and future browsers that followed standards. The hacks/compatibility workarounds for non-standard IE issues would already have been dutifully contained and locked to the specific browser versions with the issues.
It's funny how it worked out that IE 7 suddenly started to render XHTML pages like this PROPERLY in standards mode, having fixed the XML processing instruction bug that triggered the IE 5/6 quirks mode for XHTML strict documents. HTML pages using the HTML comment before the DOCTYPE still render properly and in quirks mode in IE 7. All of this WITHOUT CHANGING ANYTHING.
There is absolutely no reason pages should have broken when IE 7 came out if developers were competent to begin with and coded defensively. I mean, come on, the information has been available since IE 6 came out and quirks mode rendering workarounds have been increasingly available throughout this time for use in your conditional-comments targeted stylesheets.
On another note: it is the very people at A List Apart who recommended this ignorant meta tag proposal to Microsoft, that were also responsible for teaching so many unsuspecting novices to standards-compliant web development to trigger and use IE 6 "standards mode" knowing full well that that mode was far from compliant and was subject to future breakage as the mode was updated with each future IE release (at least until IE caught up to modern standards-based rendering levels).
I mean, do you think their solution could possibly be well-conceived when their foresight is obviously so bad?
Come on, Microsoft! Open up a discussion on this issue before blindly taking the first potential solution that falls in your lap and forcing us web developers and customers whom are both yours and ours to deal with the potentially massive blowback!