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.
shout "SURPRISE!" in unison.
> I doubt Acid2, nor Acid3 will have Microsoft extensions in them.
But lots of web pages will.
News at 11.
Have gnu, will travel.
Another Microsoft "We'll do it our way, and you'll do it our way too if you know what's good for you."
I wish Microsoft would at least learn to fake sincerity in actually following common standards. This isn't even lip service. This is "We follow standards (for certain Microsoft-centric values of 'standards')."
Of course, the market has rewarded them, so why should they change? All they need is smoke, some mirrors, and some moderately-skilled PR, et Voilà! "standards-compliant!"
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
Therefore, if you are against Microsoft, you must be a terrorist.
Please report yourself to the nearest detention center for correction.
In other news, many Americans against government bailout of mortgage companies that made bad loans...
--Phillip
Can you say BIRTH TAX
On a purely philosophical point... what is the use of having an international standard if the said standard changes based on the whims of a single corporation?
I get your point, and you may have a more real-world-ready opinion than some of us, but I am not ready to concede anything to MS in this regard.
There are other ways MS could address this issue rather than continuing their embrace extend destroy strategies. There is no reason IE specific tags should be required to make a page display according to an international standard.
If anything, broken pages should require tags to inform the browser that they do not conform to standards, and thus require special attention - not the other way around.
ACID is designed to test a browser's adherence to a set standard. Its not designed to just 'test' a browser to see if it works. It's designed to see if it works the way a browser should. I say break the millions of web-pages and force them to get updated.
Firefox 3 should be ale to pass the acid 2 test. They have been working on it, and they don't introduce custom extensions to doctypes to render correctly, rather they are fixing their browser itself.
MSFT dug itself into a hole. instead of getting out and filling the hole back in they are digging another hole to bring people down to their level.
i thought once I was found, but it was only a dream.
IE (just like Firefox, etc.) has a "quirks" mode which renders things in a non-standards compliant way, but is designed to "more or less work" with all the pages out there that are not strictly coded. This new tag is supposed to apply to web-pages where the web author has already explicitly said he wants strict rendering, because he said so in the DOCTYPE. But instead of just fixing IE so that it renders that standards-compliant code better and better, they propose to freeze that rendering sub-engine, and force web-developers to add a new tag that basically says "yes I really meant I wanted you to render strictly!"
It seems to me that the majority of pages that rely on rendering quirks will be okay, since they will be rendered in quirks mode. But pages that were intended to be standards-compliant should be treated as such.
Microsoft's plan isn't sustainable or elegant: they basically want the entire web-community to add another tag each time MS releases a new version of IE. (If they want a custom tag for the IE7->IE8 transition, they probably will want a new one for the next transition...) The entire point of these standards was to get away from browser-specific tags and hacks. A web developer shouldn't have to think about what browsers are on the market today (or 3 years from now): he should just code to the standard.
Put otherwise: Instead of asking everyone who has written a standards-compliant page to add-in a non-standard tag to make it work in IE... wouldn't it be easier to tell everyone "hey, if you've coded a page that is ~almost~ standards-compliant, but relies in some way on IE7-specific behavior, then add in this <NotQuiteStandard> tag, and IE8 will render it like IE7."
1995 called, they want their and tags back
Custom electronics and digital signage for your business: www.evcircuits.com
The real problem isn't on the browser side. It's in Dreamweaver, the most popular web page design tool. Dreamweaver does not create valid HTML or XHTML. Not even close. Create a page in Dreamweaver for anything later than HTML 3.2 and run it through the W3C validator. It will fail.
The basic problem is that the Dreamweaver people never really figured out what to do about CSS. In theory, CSS is supposed to have some abstract model of the format of some block of text, like TeX does. In practice, there's usually a big block of CSS with machine-generated names at the beginning of the web page. There's a fundamental disconnect between the CSS model and the Dreamweaver "Properties" box. So Dreamweaver is still inserting I, B and FONT tags.
In layout, Dreamweaver does table-based layout quite well, but DIV/FLOAT/CLEAR layout isn't handled well. Much of this is due to the limitations of the DIV/FLOAT/CLEAR approach. Tables are a 2D grid system, and map well to the drag-the-lines editor in Dreamweaver. DIV/FLOAT/CLEAR doesn't map well to a visual layout editor.
The end result is a mess. And HTML 5 doesn't help.
No, that's not at all the case.
Way back when the web was first taking off in a big way, browser vendors were adding lots of proprietary element types and attributes. Most of them weren't very well thought out, but there was a pressing need to get them into a specification to ensure interoperability. The result was HTML 3.2, with a lot of stuff that really shouldn't be in there.
The next version of HTML took all these out again because better ways (e.g. CSS) had been developed to handle their functionality. Of course, there needed to be an upgrade path from HTML 3.2 to HTML 4, so the W3C published HTML 4 in two major forms — a backwards-compatible document type, called "Transitional", and a modern document type, called "Strict".
That's what the "strict" refers to in the doctype. It's got nothing to do with rendering modes.
Now, when Internet Explorer 5 for the Mac was being developed, Microsoft realised that they couldn't improve its conformance to the specifications without breaking backwards compatibility. They came up with a hack that guessed whether to be backwards-compatible or specifications-compatible by looking at the doctype to see if it was there, if it was out of date, etc.
This "doctype switching" is a proprietary, non-standard hack, that happened to catch on amongst browsers. The fact that a document refers to the strict doctype does not imply that the developer is choosing a particular rendering mode, it just means that they are using a modern document type.
No, this is exactly what they are doing, and this is the very reason why such a switch is necessary.
No, this isn't the case. Any developer who wants Internet Explorer to use its most recent rendering engine at all times can select "edge" and be done with it.
Yes, and this is an attempt to do just that. Doctype switching is a proprietary hack. <meta> is the standard HTML method of including metadata. Furthermore, providing a switch like this allows them to slowly deprecate the older rendering engines over time.
No, this would cause mass regressions because there are a hell of a lot of unmaintained websites out there.
Bogtha Bogtha Bogtha
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.
Most consumers don't know they even have a choice.
New standards don't mean anything if no one uses them. A non-developer switching to a browser like Firefox simply because it "supports standards" would be like buying a high definition television fifteen years ago; you're still getting the same quality broadcasts.
W3 standards don't catch on because they're not intended for the end-user, they're intended for developers. End-users don't care that the columns on your website were coded in CSS rather than a table. If you want people to switch to a more developer friendly browser, you have to give 'em the old razzle dazzle. For example, let's say Macromedia Flash was introduced later in the game, relied on a W3C standard instead of a browser plugin, and that standard was only supported by non-IE browsers. Developers would be so anxious to use Flash that they would leave IE users in the dust, encouraging them to switch if they wanted to see the fancy dynamic content. IE users would then feel left out and switch to Firefox, which would end up with a 70% market share before Microsoft could even blink.