On the IEblog there is this post about compatibility and IE8 and how they will introduce lots of new quirks modes for each new Internet Explorer release, starting with IE8. It appears that they managed to convince “the experts” of the Web Standards Project to deliver the message on no less than A List Apart. Fortunately, the comment crowd does not seem to be buying it. As it turns out the Web Standards Project as a whole was not aware of this until publication on A List Apart.
How the hell can anyone possibly believe that we can preserve documents from the past by only making them readable with a specific rendering mode from Internet Explorer? The same article already talks about the problems with importing older Word documents. Isn’t that a sign that if Microsoft tries the exact same solution for the Web as they did with Word, things might go wrong? What the …. It concludes with the hope that other browser vendors will follow this insanity. Hell no!
If anything, we want less differences between quirks and standards mode. They are already causing a lot of trouble. That Eric Meyer, who once worked for Netscape, suggests that this would give us more time to do cool stuff is simply wrong. Quirks mode is costing us time that we could have otherwise spent on implementing cool features. Certainly not the other way around.
Solutions? We can ignore this all together. We can get popular Web server software to set IE=edge. We can convince the world to use a browser that does not have the ability to lock pages into a specific rendering mode. Bah.
Microsoft's failure to keep up with standards that are in wide use today suggests strongly that the problem isn't web authors' inability to keep up with IE, but IE's inability to keep up with the web: the web itself is a lot faster-moving and more fluid than IE has been in the best part of a decade, and Microsoft just plain isn't used to it.
I think the IE team is smokescreening: in my experience, it's not the rendering engine that has issues (Firefox in quirks mode copes just as well as IE with the vast majority of sites out there), but the JScript engine and ActiveX. Oddly enough, JScript- and ActiveX-specific code is a lot harder to fix than Trident-specific “HTML”. Worst-case, IE just needs a “quirks mode with the old JScript engine”, rather than a plethora of different quirks modelets.
In real terms, though, it's not worth the effort. Release a version of IE 6 than can be installed standalone and let the tiny handful of corporate users with weird intranet applications use it, and everyone else will use IE 8 with similar quirks/standards-compliant switches as Firefox (though I'd really prefer it if didn't resort to DOCTYPE sniffing to accomplish it…) and nothing more.
Thanks MS... Thanks for making us update *every* site we have yet again...
What i think wóuld be a good idea is to turn this exactly around: add a meta tag or http header to sites that need to be rendered by IE8 in 'crappy-mode', 'ie6 mode' or 'ie7 mode' and kick it into standards compliant mode by default. That way, the rest of the web will work as it was once visioned and you only need to adjust whole webservers serving for old sites. One could upgrade to IE8 ánd you can still trigger quirksmode if neccesary.
Standards mode should be OPT-OUT instead of OPT-IN
Imagine anyone trying to build a brand-new web browser. How the heck are you supposed to treat all those pages that are labeled, not just for other versions, but for completely different browsers?
The world is definitely getting weirder; why not just start add some new propriety tags to the mix, it cannot harm any more than this new crazy idea.
Anne,
Would other non-IE browser vendors agree with you (Mozilla, Webkit)? And does Opera ever experience massive breakages with new browser releases, or is this just a Microsoft problem?
I'm not convinced that this solution will actually get MS anywhere. I mean will it even work?
Jonathan
@Anne: AMEN brother!
It appears that they managed to convince “the experts” of the Web Standards Project to deliver the message on no less than A List Apart.
Just to be clear Anne, the members of the Web Standards Project in general were not informed about this article and Microsoft's proposal/plans until it was announced on A List Apart. Any Web Standards Project members who consulted with Microsoft did so as individuals and not as representatives of WaSP.
I am sure that I am not the only WaSP member (and web designer/developer) who is unhappy with these proposals on first reading.
Thanks for the clarification Andy!
Jonathan, Robert (developer from Mozilla) does not see the need for it and I’ve heard similar statements from Maciej (Apple) in the past.
Solutions? We can ignore this all together.
Ignoring issues seems convenient but there's a high risk that things get worse in the end than if we didn't ignore it.
We can get popular Web server software to set
IE=edge.
No. This only leads to IE9 getting a different mechanism for the opt-in switch, because, obviously, if a lot of pages uses "IE=edge" without the author's consent, IE9 would break all those pages, and that wouldn't be acceptable to MS. So we end up with yet another switch.
We can convince the world to use a browser that does not have the ability to lock pages into a specific rendering mode.
Yes, but how?
I wouldn't expect IE8 standards mode to be on par with other browsers' standards mode. People expected IE7 to be CSS 2.1 compliant, but it was the same IE with some bugs fixed, some new features, and a bunch of new other bugs.
For damage minimization, I would recommend Web developers to not use IE8 standards mode, as tempting as it seems. You still have to work around IE7. You know what the workarounds are. Continue to use quirks mode or "IE7 standards mode", whichever you use today. If people don't use IE8 standards mode, then MS won't break many sites by continuing to improve "IE8 standards mode", and thus they don't have any reason to introduce yet another rendering mode for IE9.
@SchizoDuckie: I just had the same idea you did. Why put the burden on us? Let IE8 be standard compliant but give those who need stupid-mode a simple and easy band aid to fix their problems.
zcorpan: if everyone uses IE7's rendering model the MS has no incentive to develop an IE9 full stop.
Robin: of course they do. I don't understand how you come to this conclusion.
If they don't release new versions of their browser, they will loose market share; they learned that with IE6.
They might, however, have an incentive to revisit their decision about introducing new rendering modes. Perhaps fixing bugs and introducing new features in quirks mode and "IE7 standards mode" isn't such a bad idea after all.
Now, I don't expect IE8 standards mode to be a complete market failure, but it seems to me that it would be the best in the interest of the Web if it was.
Funny how you're so against it now when this is very, very similar to what you yourself proposed three years ago.
Faruk, heh, I was once in favor of XHTML, XHTML 2.0, et cetera too. I’m willing to change my opinion in light of new evidence :-)
And changing your opinion / point of view is a totally acceptable (and, I would dare say, smart) thing to do. :)
However, I'm on the fence between your current outcry against this proposal and your proposal of a few years ago. Also, I believe the ideal solution here is actually found somewhere on this fence.
The beauty of your old idea was that it didn't require other browsers to adjust their pursuit of standards-support; e.g. the default behavior for any browser would still be to be as standards-compliant as possible. The current proposal from MS defies that by asking other browsers to follow suit. I don't think that should be necessary at all.
It appears that they managed to convince “the experts” of the Web Standards Project to deliver the message
Well they didn’t convince me. I’ve been opposed to this idea from the start.
I think supporting application/xhtml+xml would have been a good way for IE to do their "super standards mode" - except that it forces developers to move to XHTML for their web pages. And these days, there are quite a few people dismissing XML for this purpose due to the draconian error handling. It would have left those people still wanting to publish HTML hung out to dry.
Btw, I still think it would be great if IE did support the XHTML MIME type without a need for <meta>. I'm not going to hold my breath though.
This <meta> tag thing is sad, but I don't think it's the end of the world. I, for one, will be striving to use "IE=edge" going forward. I think this is what web developers who care about the open web need to be doing (to prevent IE-8 mode from becoming the defacto standard and force another round of browser reverse-engineering)
I strongly agree with you, Anne. There probably is a (much) better solution for being backwards compatible and improving web standards support.
Also, I would like to toss a new problem that may occur (I think). I haven't seen anyone thinking about it, but would all those rendering engines take a lot of memory? If only three rendering engines of IE need to be loaded, that would slow down your browser experience. Okey, in the future we all have more memory, but that doesn't make sense to me.
Arjan, I discuss implementation issues in my blog. Summary: it's a nightmare at several levels.
Arjan, not just the memory usage.
Picture this:
Now try to reach inside the second level iframe from the IE8 document. In how many different DOM's from render engines with how many specific bugs will you get?
This will cause madness and many, many headaches if you ask me..
Looking deeper into this, it's a complete and total non-issue.
The big deal is that the mess that was IE 6 caused IE 6-specific hacks and workarounds to apply to IE 6 and IE 7. The fix (conditional comments, primarily) if used in any sort of sensible manner will cause a miniscule number of issues when IE 8 arrives, and most web developers (having been bitten once by the transition away from IE 6) will be shy of making the same mistake again.
Beyond that, there's the philosophical: (a) all of this came about because IE 6's implementation of “standards mode” was broken, so why should we clean up the mess even more than we have to already, (b) standards-compliant pages are already pretty much labelled as such (at least to the extent that it causes a quirks versus standards mode switch), why should we have to label our pages as such?, and (c) are Microsoft saying IE 7 is broken, and if so are they going to document its flaws and the best-practice workarounds in order to avoid causing future breakage?
@Jeff: I agree that the a separate MIME type would be preferred over a meta element, but I also think that draconian error-handling is precisely what's required, at least for any browser used by a developer (the same arguments apply to turning on warning flags in C compilers: you do it if you care about the quality of your code). It's not hard to produce well-formed XML. It's not even remotely close to hard, in fact. Browsers used by developers should give you a big yellow screen, and browsers used by end-users should pop up the pop-up notification-style warning strip informing the user that the web developer screwed up—the developers would fix their pages pretty sharpish if that happened.
Mozilla developer Robert O'Callahan sums it up short and sweet:
<META HTTP-EQUIV="X-BALL-CHAIN">
"I think supporting application/xhtml+xml would have been a good way for IE to do their "super standards mode" - except that it forces developers to move to XHTML for their web pages. And these days, there are quite a few people dismissing XML for this purpose due to the draconian error handling."
I serve my pages up as XHTML. In fact, with one of my sites, I don't provide an HTML only workaround -- it's served up as XHTML 1.1, period. Because of this, I know immediately when I've done something wrong in a post, and can fix it quickly. I suppose an environment that forgives errors is more amenable, but probably leads to crappy sites.
I can also embed RDF/XML and SVG easily into my pages. In fact, my pages live on the threshold of an open door--which is more than what one can say with any HTML solution.
And now we're supposed to close the bloody door because Microsoft is not willing to admit it made mistakes in the past, and have these mistakes thrown into its face? No. That's like sweetening organic fruit with high fructose corn syrup--it contaminates the goodness.
I serve my pages up as XHTML. In fact, with one of my sites, I don't provide an HTML only workaround -- it's served up as XHTML 1.1, period. Because of this, I know immediately when I've done something wrong in a post, and can fix it quickly.
Good for you, but this doesn't address what you quoted. It's far more of a "boil the ocean" approach than what has been proposed. And it doesn't work for the web that exists right now.
I'm tentatively in favor of this solution, but I agree with Anne's assertion that clueful web designers/developers will want to use IE=edge as their default. It most closely resembles the model of the Web that I implicitly agreed upon when I started building my pages with Web standards in mind.
I serve my pages up as XHTML. In fact, with one of my sites, I don't provide an HTML only workaround -- it's served up as XHTML 1.1, period. Because of this, I know immediately when I've done something wrong in a post, and can fix it quickly.
Do you have a way to know immediately when someone else does something wrong? That's a mildly unpleasant denial-of-service vulnerability for any site that shows one user's content to another user, and I haven't yet found an XHTML site that accepts user input and doesn't have this kind of bug...
@Philip: my site used to, back when I still ran it on a CMS. It's all static now so I've made it use text/html but I made my site user-proof and XML-compliant, just kind of to prove a point. It's possible, but it does require kind of aggressive stripping away of invalid characters/encodings. Well, that's the easy way to make it work, anyway.
Your point is still totally valid though — XML's draconian error-handling is just no good at all from a user's PoV, and shouldn't ever be part of the user's life, only the developer's.
Hrm, so we can either take the blue pill (the meta switch):
Prolong the life of bug-dependant, browser-dependant sites forcing browser developers to deal with the problems caused by that.
Prolong the life of buggy web browsers which will still be usable due to all the prolonged-life bug-dependant sites, therefore prolonging the pain faced by web developers.
~~~~
Or the red pill (a version of IE that works _correctly_ by default):
Sure, some sites will break. Great! Fix them or watch them fade to obscurity. Fewer bug-dependant sites for browser developers to worry about. Problem solved.
People with buggy browsers will experience pain and either upgrade their browser or stop browsing the interweb. Fewer broken UAs to for site developers to worry about. Problem solved.
~~~~
I really can't simplify my view on this any further than the pills described above.
Microsoft's latest attempt to hold on to their browser monopoly is just plain wrong, and indeed evil. I'd go so far as to say it's a crime against humanity because it guarantees long-term pain for web developers, browser developers and people who use the interweb, when a blatantly simple (although short-term pain-inducing) long-term solution is there for all to see.
My choice: Red pill.
Let's just bite the bullet and go for standards compliant, deal with the short-term pain and enjoy the long term gain. Create a feedback-loop that gives increasing incentives to everyone involved to move to standards compliant.
What Microsoft wants to do really is to just delay the bigger problem until some other day, which simply allows for the problem to get bigger. It is like a temporary fix that will simply make things more difficult in the long run. Maybe they are just thinking by IE10 that the web browser will be replaced by something else and they won't have to worry. Otherwise, there really is no justification.
People with buggy browsers will experience pain and either upgrade their browser or stop browsing the interweb.
That's just not true at all, however. In the real world, what happens most is either a) the user gets a bad user experience but doesn't know who to blame or b) the user gets a bad experience and blames the web developer / owner of the site.
Vile justification-driven points of view don't make for a good business strategy, and are thus not useful to most of the people this whole thing concerns. "Serves them right!" is exactly that.
@Faruk: Ok, why don't they make IE8 be standards-compliant by default (it's not caused problems with all the other browsers has it?) and have a meta (hack!) tag that says "run as IE7" for bug-dependant sites?
A great number of sites that work on IE7 will already work on IE8. Some might need subtle CSS changes (ie. wholesale removal of hacks) and the really bad offenders can beg for IE7 with the hack tag.
This would:
I think free software would appear very quickly to add the "beg for IE7 hack" to all HTML files in a folder structure and any form of CMS can very quickly be tweaked to add it in as well.
There are a finite number of existing web pages on the internet. There are an infinite number of future web pages that will appear for the rest of time. Why is the hack tag being imposed on the latter when it would only be needed on a fraction of the former?
We can't hold on to the past forever, especially when it causes so much pain and suffering. Surely you can see that?
Philip Taylor said,
I haven't yet found an XHTML site that accepts user input and doesn't have this kind of bug
I haven't previously had the chance to thank you for your previous efforts beating on Instiki. I don't know whether it (or my blog, which runs on a heavily hacked version of MovableType) is completely impervious to such attacks, but it is much improved.
If you're so inclined, I'd be grateful to hear of any other ways you might find to introduce ill-formed content in either Instiki or on my blog.
The good news is that MS finally seems to have found a way to have IE6 and IE7 running on the same computer without mixing up the version numbers and such ;-)
Re comment 3 from SchizoDuckie and comment 11 from paul:
What i think wóuld be a good idea is to turn this exactly around: add a meta tag or http header to sites that need to be rendered by IE8 in 'crappy-mode', 'ie6 mode' or 'ie7 mode' and kick it into standards compliant mode by default.
That is exactly how this metatag will work.
Imagine a site, built with/for IE 6. Luckily IE 7 didn't break anything. Firefox and others could go to hell, though, it didn't matter.
And now IE 8 comes out, fully compliant to standards, finally being on par with Firefox, Opera, Safari, Konqueror et al.
And now this site breaks horribly. What to do now?
Easy solution: Just add this metatag or add it in the HTTP header to at least switch IE 8 back into conforming rendering mode.
You get everything you want: IE 8 finally standard compliant, and doing it by default - and you have an easy back door for those webmasters, who either do not care enough, or who need a quick solution until the relaunch can take place applying standard conformance at last.
If you're so inclined, I'd be grateful to hear of any other ways you might find to introduce ill-formed content in either Instiki or on my blog.
I guess there's this (and I don't know what would happen if I actually created that page). But I've not been able to find anything else :-(
That is exactly how this metatag will work. [...] You get everything you want: IE 8 finally standard compliant, and doing it by default
aeh...sorry sven, but no, that's not how this metatag will work according to the proposal. IE8, IE9, IE10, etc will render as IE7 by default, unless you the developer specify that you actually did the right thing and coded it according to standards.
to further clarify: so you need to the metatag when you know for sure that your page doesn't break horribly in the new version.
Andrew, I'm in a rather boil the ocean mood.
Philip, I imagine I have vulnerabilities at my site. As they arise, I work on fixing them. I'm using Wordpress, which isn't particularly XHTML friendly. I'm also not the markup expert, like Jaques, who has shown me some of my vulnerabilities, but I try.
The operative term here is 'try'. Isn't that the important point? Seems to me, IE=edge isn't the same as 'trying'.
I guess there's this
Thanks! Fixed.
(and I don't know what would happen if I actually created that page).
Nothing. It won't let you create page names which are not valid utf-8.
But I've not been able to find anything else :-(
I would take that as a good sign. But, to paraphrase John Philpot Curran the price of XHTML is eternal vigilance.
Oh my head hurts and especially after reading all (half) the comments on the IEblog for Chris Wilson latest post.
This is just complete meta madness. I see Anne that you quote "the experts." The ones I think I know seem to be playing this game of hide and seek with the development community about IE8.
I wish I had my own alpha of IE8 to play with. I have some test cases already up (or completed) for this purpose.
"Your point is still totally valid though — XML's draconian error-handling is just no good at all from a user's PoV, and shouldn't ever be part of the user's life, only the developer's."
I don't want this to get off-topic into XHTML, care and feeding. I can agree that the extreme error handling of the page can be intimidating, but it's no different than a PHP page that's broken, or a Java application that's cracked, or any other product that hasn't been put together right.
But speaking of draconian, we've all been suffering Microsoft's 'draconian' error handling for the last half dozen years. We've indulged in an amazing set of kludges, just to get pages that 'look' OK to people using IE 5.x or IE 6. Worse, we've held off using some of the newer standards-based innovations because they don't work for IE.
Now, we're all set to add yet another element to the page that none of us wants. Why? So that we help the company maintain the illusion that it is the best and the brightest--after all, look at how many sites implement IE-specific technology. If all the sites that should break with IE actually allowed themselves to break--to look ugly, to show the true worth of the browser--would IE still have the same market share it does?
I don't want this to get off-topic into XHTML, care and feeding. I can agree that the extreme error handling of the page can be intimidating, but it's no different than a PHP page that's broken, or a Java application that's cracked, or any other product that hasn't been put together right.
Actually, it is very different. The draconian error handling of XML means that with 1 single error, the user gets nothing. PHP's error handling is far from draconian. Sure, it's possible to botch up a PHP script badly enough that it will give the user nothing, but this is not inherently the case. Generally (and this really is the vast majority of cases), what happens is that PHP throws some errors at the top of the page and the rest of the page gets rendered as normal, or as normal as it can be depending on what part error'd out and broke. That's a huge difference from XML's handling.
As for the whole "if all the sites that should break with IE actually allowed themselves to break" part… it's great that you think about such purely hypothetical questions, but the world runs not on ideologies but on business, and the most basic business sense will prevent such a thing from ever happening.
@Sven: In your scenario, there's no reason why it would break in IE 8 (unless IE 8 was broken, in which case you'd need to do more than just add a meta element to fix it).
The solution to the “targetting one specific version of IE” has existed for some time and is widely used (at least, has been widely used since the IE 6 to IE 7 transition): conditional comments. They may be a bit of a hack, but they accomplish the same thing in the correct way (standards-compliant by default, dumbing down where appropriate), which means that if IE 8 is standards-compliant there will be approximately zero issues.
Seriously, that's all there is to it. This is nothing like the IE 6/IE 7 transition—the notion of “breaking standards-compliant sites” with a standards-compliant browser is so utterly nonsensical I thought it was a joke. The number of sites that'll break as a result of IE 8 adhering more closely to the specs than IE 7 will likely be counted on the fingers of one hand, and each of those instances will be fixed by changing the existing conditional comments to target “ie 7” instead of “ie gt 6” or “ie gte 7”
Beyond that, this is what “release early, release often” is for.
@Sven: my apologies, you said “works in IE 6, IE 7, breaks in everything else”. It's highly unlikely that such a site would be using the standards-mode renderer in the first place, so again it's irrelevant.
"I don't want this to get off-topic into XHTML, care and feeding. I can agree that the extreme error handling of the page can be intimidating, but it's no different than a PHP page that's broken, or a Java application that's cracked, or any other product that hasn't been put together right."
I don't want to get off-topic either but I hear this nonsense a lot. You can't simply compare a markup language with a programming language. They have very different intended authors (normal people versus programmers) and very different purposes...
... (normal people versus programmers) ...
What's so abnormal about programmers then? ;-)
But seriously, I guess you mean that programmers are specialists. But are front-end developers not specialists either?
I think the <meta> solution is okay, had it only been the other way around. Instead of opting in to support web standards (just writing it makes me squint because it's so insane), people should opt out. The existing web pages that are tailored to a specific version of Internet Explorer should state explicitly which version of IE they are tailored for.
That's the only thing that makes sense, since those old and arcane pages are the only ones that are, infact, tailored to a specific version of Internet Explorer. Newly created web pages are usually following standards and only implement hacks to get around IE's rendering bugs. Labelling those standards compliant web pages as targetting a specific version of IE is just confusing and right out wrong.
I don't want to get off-topic either but I hear this nonsense a lot. You can't simply compare a markup language with a programming language.
I fail to see the relevance of the distinction. Philip Taylor was talking about dynamic websites, where the markup is generated programmatically. So, by extension, was Shelley. Either the program (written in PHP, in Shelley's case, or in Perl or Rails, in mine) reliably outputs well-formed XML, or it doesn't. In the latter case, this is called a programming bug.
There's no particular reason to distinguish this class of programming errors from other classes of programming errors. (I can see the argument that Postel's Law ought to apply to both, but that's a different argument.)
This is vaguely relevant to the discussion at hand, because the IE Team is promising to preserve, in amber, their own programming bugs for perpetuity. And they are suggesting that other browser developers do the same. That seems kinda silly, but the part I find disturbing is that Eric Meyer seems to think that this promise is reason to abandon "forward compatibility" or "progressive enhancement" (or whatever buzzphrase you wish to use to describe it), in favour of targetting a particular browser version (bugs 'n all).
That would pretty much spell the end of progress in Web Standards. To ask a rhetorical question, which version of IE should I target with my site?
The given announcement is great support for your antitrust complaint.
I fail to see the relevance of the distinction. Philip Taylor was talking about dynamic websites, where the markup is generated programmatically. So, by extension, was Shelley. Either the program (written in PHP, in Shelley's case, or in Perl or Rails, in mine) reliably outputs well-formed XML, or it doesn't. In the latter case, this is called a programming bug.
Very true.
We're not asking people to become markup experts, but we are asking that tools do a proper job. People don't have to become XHTML experts if tools do an their job and generate well formed XHTML. In a way, it should be easier than having to deal with the quirks built into HTML.
The so-called 'normal' people rarely use any markup of any form. They use tools such as Wordpress or DreamWeaver or the like. These tools, created by abnormal developers, are the ones that should ensure properly generated markup regardless of whether the markup is HTMl 4.x. XHTML, or HTML5.
The problem, though, is we still don't have enough support for XHTML, because we have one major browser, IE, that persists in serving up XHTML as a pile of gibberish no matter how well formed. It undercuts the ground beneath efforts like XHTML, SVG, and even HTML5.
Now, not only is it unlikely that IE8 will support XHTML, it forces this foolish piece of garbage on us and manages to convince some people who are respected in the community to get together behind closed doors and come up with 'a plan' to coerce the web designer and developer community into, yet again, marching to Microsoft's twisted tunes.
No involvement with the other browser makers. No transparency into the process. Not even one public comment before pushing this out as an accomplished act.
What I've read from Zeldman, the WaSP members behind this, ALA, and the few other 'invited' experts is that we have to support this...or else. We're not given a choice. We're not even really invited to comment--not without getting scathing responses in turn by these same 'experts', who sneer at our responses as if we're the great unwashed.
Well, my serving up web pages as application/xhtml+xml is my choice, and by Microsoft's inability to support standards such as XHTML, sure as heck makes the use of this newest quirks mode moot.
Huh? What is the actual complaint here? I understand some people are extremely doubtful Microsoft can pull this off, since it is a difficult software problem. But what is the complaint about the theory exactly?
I have the option to lock my web pages to the version of IE I tested it with? Thank you!
Microsoft now can deploy browsers with more standards compliance because they don't have to worry about breaking backwards compatibility? That sounds like exactly what we've all been asking for! But now we don't want it? What?
The opt-in vs opt-out argument is silly. Microsoft isn't going to purposefully break websites. People wishing this would happen just sound crazy, and make us look crazy, and generally hurt the push for a standards based development.
In real terms, though, it's not worth the effort. Release a version of IE 6 than can be installed standalone and let the tiny handful of corporate users with weird intranet applications use it, and everyone else will use IE 8 with similar quirks/standards-compliant switches as Firefox (though I'd really prefer it if didn't resort to DOCTYPE sniffing to accomplish it…) and nothing more.
I propose that the IE 6 re-release be named "Intranet Explorer" ;-)
Actually, it is very different. The draconian error handling of XML means that with 1 single error, the user gets nothing.
Sorry, wrong. That’s how Gecko does it, but that’s Gecko’s (regrettable) choice. Safari f.ex. will render all the data it managed to parse before the parser hit the well-formedness error. This is perfectly legit: the XML spec does not require applications to throw away the data they got from the parser before a WF error is encountered – its only edict is that the parser stop parsing.
The proposed method is simply a way that Microsoft can perpetuate the current situation, in which inertia favors IE and worse, IE-specific web sites, while being able to give lip service to standards conformance. It should not be necessary to insert a non-standard item to get standard-conforming behavior.
You know, -I really hate Microsoft. Seriously. It's just a shame that I have to use some/many of their lameass products to get my job done.
Don't send IE=edge. Microsoft will take it as IE=8 and introduce new "edger" switch in IE8.
If you want to be more annoying, use IE=${random(9,12)}, but the best solution is to ignore it altogether — only then they'll change support of unlabelled content.
The effect of ignoring the proposed opt-in switch:
"I look forward to watching IE market share take a nose dive the minute you release IE 8 with any such opt-in switch that effectively locks YOU into developers who effectively stop IE rendering progression at IE 7 by IGNORING your ill-conceived switch.
If you thought your market share declined during the hiatus, JUST WAIT until every new version of IE appears to visitors to be EXACTLY THE SAME AS THE LAST (so, why bother upgrading?) compared to other browsers that just seem to make pages look better and better with each release.
Turnabout is a BI*CH."
so, why bother upgrading?
Indeed, we'll still have to provide conditional comments for IE6 and IE7 for the coming 5 years. Hooray :)
We owe it to ourselves:
Give them something to do, other than coding the original proposal!
We owe it to ourselves:
Alternatives NOW!
See here for a breakdown of the problem and start helping out on an alternative solution:
Web developers unite!
Hey,
This is unrelated to the post, I'm not sure if you've noticed (or if you even care) but your layout is broken in FF 3.0b2. It forces a horizontal scrollbar.
Gianni
It's all the result of Microsofts reluctance to finally adopt the web standards. Instead of designing a fully standards compliant browser they try to resolve the problem of proper rendering with their own ideas which as always leads to a general uproar among the public. Mixing things all the time isn't a solution, just adopt the standards! Should anyone be interested in Polish translation of the WaSP article on this matter please refer to my website.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 8.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
The above code raises some interesting questions. This should allow IE8 to render a page in standard mode without any special meta. If you haven't studied closely, it's an unknown doctype. After discovering that such a doctype validates either via the W3C validator as valid XHMTL 8, I have realized that these doctypes can just fade away and we can usher in the era of xml compatible browsers. With this desire by MS for this new meta, I now believe that IE8 is not a xml compatible browser.
Couldn't this be solved in a much simpler way?
Wouldn't this lead to a situation where:
and all this with no new tags...
or am I missing something?
Ah as a web designer, I think IE is just playing games again. Instead, I am gonna convince my CEO to talk to all our clients and get them to use Firefox or Safari or Opera !!! I dont want to install X amount of IE on my poor machine and watch it crash and burn and i really DONT want to learn IE8 hacks :D lol Chris