Forgot your password?
typodupeerror
Internet Explorer The Internet

IE8 May Not Pass the Acid2 Test After All 434

Posted by Zonk
from the follow-me-indy-i-know-the-way dept.
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."
This discussion has been archived. No new comments can be posted.

IE8 May Not Pass the Acid2 Test After All

Comments Filter:
  • Page specific tuning (Score:5, Interesting)

    by mini me (132455) on Wednesday January 23, 2008 @02:06PM (#22155692)
    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.
  • by Ohio Calvinist (895750) on Wednesday January 23, 2008 @02:13PM (#22155788)
    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.
  • by ozamosi (615254) on Wednesday January 23, 2008 @02:15PM (#22155806) Homepage
    The author of Acid2/3 is not amused [hixie.ch] by this meta tag. From the tone of that blog post, to me it sounds like he wouldn't shy away from actively try to break a mechanism like that by changing the URI to make sure that the browser that passes the Acid test actually does so for real.

    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)

    by Mongoose Disciple (722373) on Wednesday January 23, 2008 @02:22PM (#22155920)
    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?
  • by TheSunborn (68004) <tiller@daimi. a u . dk> on Wednesday January 23, 2008 @02:24PM (#22155962)
    but all theese millions of pages pages render fine in firefox, using standard mode so why can't they render fine in ie8?

  • by Rakishi (759894) on Wednesday January 23, 2008 @02:25PM (#22155974)

    As such, ACID should be updated to include the new doctype option for IE.
    Given there is is going to be no new doctype, from what MS is saying, this won't be of much use. Of course had you read even the article SUMMARY instead of ranting about how people shouldn't bash MS you'd have known this. Then again you can't karma whore by being reasonable and responding to the actual issue instead of a strawman so I guess that's out of the question for you.
  • Two pages for IE (Score:2, Interesting)

    by Phillup (317168) on Wednesday January 23, 2008 @02:26PM (#22155984)
    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.
  • by alexgieg (948359) <alexgieg@gmail.com> on Wednesday January 23, 2008 @02:35PM (#22156140) Homepage

    Why not make Acid2 the default?
    Because lots and lots and LOTS of pages would break, among other things. Earlier today there was another article in ./ with a link to the full rationale behind this [alistapart.com], and to me is makes a lot of sense. Basically, with this tag you can specify a version for each browser on which the site was tested and is known to work well, then all browsers might keep internally working versions of their legacy rendering engines (or a compatibility mode built in their newest engine, whatever works best in each case), and forever in future you'd have old sites being 100% readable in new browsers, no matter how much actually existing "de facto" and "official" standards change or get deprecated/replaced over time. An example from the above link, specifying the page renders correctly in IE 8's engine, Firefox 3's engine and (say) Opera 4's engine:

    <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.
  • by dmgxmichael (1219692) on Wednesday January 23, 2008 @02:46PM (#22156294) Homepage

    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.

  • by 200_success (623160) on Wednesday January 23, 2008 @03:55PM (#22157422)

    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:

    1. Ditch the X-UA-Compatible flag; it's a stupid idea.
    2. Continue supporting HTML conditional comments as you have been doing.
    3. Fix the layout engine and the CSS parser at the same time, so that any existing IE-specific CSS hacks become irrelevant.
    4. Add support for CSS conditional comments, to give web designers an escape route. Let's face it, CSS hacks are a reality, so we might as well have a tool to do it cleanly.
    5. Send this as the User-Agent string: Mozilla/5.0 (compatible; Microsoft Trident VI; Windows NT x.y; ...; Microsoft Internet Explorer 8.0; ...). Any server-side code doing browser sniffing, not seeing the "MSIE" string, should send a standards-compliant response. User-Agent strings have never really been logical anyway -- IE started this mess years ago by sending the "Mozilla" string, and Opera continued the trend by optionally sending the "MSIE" string -- so additional games in this area wouldn't do any more harm to the Web.
    6. In JScript, navigator.appName should return 'Microsoft Trident', and navigator.userAgent should return the string above. Client-side scripts doing explicit browser sniffing, not seeing the "MSIE" string, would suppress their legacy IE hacks.
    7. In JScript, document.all should evaluate to false (although expressions involving document.all can still behave as in older versions of IE). This approach worked for Mozilla [mozillazine.org], and it will work for Microsoft too.

    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.

  • by KookyMan (850095) on Wednesday January 23, 2008 @03:55PM (#22157424)
    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.
  • Re:Hear hear (Score:2, Interesting)

    by the_B0fh (208483) on Wednesday January 23, 2008 @04:11PM (#22157742) Homepage
    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.
  • by jimicus (737525) on Wednesday January 23, 2008 @04:14PM (#22157784)
    As far as I can gather, this amounts to the following:

    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.
  • by TENTH SHOW JAM (599239) on Wednesday January 23, 2008 @07:53PM (#22161068) Homepage

    Opera, Mozilla/Firefox don't have this problem so why should Microsoft.

    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.



  • by kodeman (794791) on Wednesday January 23, 2008 @10:50PM (#22162638)

    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!

Any program which runs right is obsolete.

Working...