Slashdot Mirror
IE8 May Not Pass the Acid2 Test After All
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."
It's possible that IE8 will contain code that detects the presence of an ACID test and switches to the proper renderer to pass the test.
Why not make Acid2 the default? I'm sure the browsers interals could look for IE6/7 "hacks" and provide a icon on the bottom to have it viewed in compatibility mode? If the broken mode is going to be the default, I think standardization will be slow, unless common developer tools like MS Visual Studio and Dreamweaver put in the MS Specfic renderer tags in by default.
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.
Forgive my spelling from time to time. I'm often posting during short breaks.
Other than being able to pass the ACID test(s), what would it really mean to Microsoft either way if IE8 did or didn't?
but all theese millions of pages pages render fine in firefox, using standard mode so why can't they render fine in ie8?
Great.
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.
--Phillip
Can you say BIRTH TAX
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.
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, 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" 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.
I read somewhere, possibly on /. that W3C had just released its first working draft for HTML5. How about have a tag in HTML5 that signifies the page as HTML5 (Which I'm sure it will) and then /all/ browsers are supposed to handle it as written. No "strict" or "loose" rendering. No quirks. Just all pages written in HTML5 (or revised up to the new standard) are required to be written correctly, and rendered "strictly.". This will give Microsoft a way out of the hole they've made, while saving some face. Leave the quirky rendering engine in place for all HTML4/Earlier pages out on the net. In a few years, drop the other renderers from the software (say around IE11) and the rest and then it will be a much nicer playground for everyone. Kind of like the Vista idea of stop being backward compatible (plan for it) so we can clean out all the trash.
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.
I despair at the IT field. Who says there's no other method of doing the right thing? IE8 has it's own agent string.
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.
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!