I’d like to live in a world where people weren’t killing each other over religious and ethnic differences and where version targeting wasn’t needed. Designing with web standards ought to be enough, and anyone who works on websites should know how to do it. Browsers ought to have near-perfect standards compliance by now, and if they don’t, their manufacturers should switch to folk music.
But manufacturers, including Microsoft, have a weird way of staying in business when their products enjoy a healthy market share (healthy for them, if not necessarily for the market). And even huge companies—for instance, companies like Microsoft—occasionally listen to their customers and try to solve problems related to their products.
To understand version targeting—which we ought to try to do, since Microsoft intends to implement it and hopes at least some of us will opt in—let us examine two different sets of customers that Microsoft’s browser must satisfy.
The quick and the dead#section2
One set of customers—let’s call them knowledgeable designers and developers—strives to create semantic, accessible, standards-based sites. They also, we hope, aim for great design, compelling and meaningful content, usable interfaces, and semi-transparent site architecture.
For this group (wave if you’re part of it), the biggest problem with IE has been that its standards compliance has never matched that of Firefox, Safari, and Opera. Particularly during the long weird years when an unchanging IE6 sat moldering in the corner, knowledgeable developers rightfully moaned that every time they built a site with standards, they had to go in and create workarounds for IE’s deficiencies. Other browsers had bugs requiring workarounds, too—but nothing like IE’s litany.
To satisfy this customer group, Microsoft had to significantly upgrade its browser’s standards compliance—and then keep upgrading it, in frequent increments. With IE7, Microsoft has begun to do that. With IE8, it will go further, particularly where scripting is concerned.
But Microsoft has another by no means tiny set of customers. We might call them the unenlightened. Some are professional developers who should have heard about web standards and accessibility by now, but either haven’t heard or don’t care. This may be because they work in companies that restrict their access to books, conferences, and even non-work-related websites—dim companies with outdated and myopic rules about which browsers and platforms shall and shall not be supported. Let’s be charitable: some of these developers work exclusively on platform-dependent intranets. Others know about web standards, but work at companies that force them to create table-based layouts, to author to IE5’s incorrect CSS box model, and so on.
Microsoft cannot abandon these web builders, nor can it hold itself blameless for their platform- rather than standards-based approach. After all, during the bad old days, companies like Microsoft and Netscape helped create ill-informed web developers, by encouraging IT folk to develop for their proprietary web “platforms.” There may even be divisions of Microsoft that still sell this snake oil, despite the company’s general embrace of web standards.
And professional developers who don’t know better are but a loogie in the bucket of unenlightened web creators. There are millions of small business owners, school teachers, pastors, coaches, and so on who create websites every day, armed with crappy software and little else. Such sites are rarely models of great design, good writing, or passable usability, and they are almost never marked up in valid XHTML or authored to anything resembling Bert and Håkon’s CSS specifications.
This unenlightened customer group either doesn’t test at all, or “tests” only in the version of IE that came with their computer. You and I may not care about these millions of lumpen web auteurs, although we would love to convert them to standards-based design, but Microsoft, being a corporation and all, can’t dismiss them. To satisfy the unenlightened, Microsoft must ensure that as IE becomes more compliant, it does not “break” the badly authored sites they create. (Break is in quotes where some might hold that a site which displays incorrectly but still functions is not necessarily broken.)
Satisfying both groups is nothing new. Browsers figured out how to do it in 2000—namely by implementing the DOCTYPE switch invented by The Web Standards Project’s Todd Fahrner. But the old trick no longer works—at least not for IE.
Riding two horses with one behind#section3
When IE’s compliance leaped forward with IE7, at least temporarily satisfying Microsoft’s first customer group, the badly authored sites created by the second customer group stopped working correctly, leaving unenlightened developers profoundly peeved.
From the outside, to readers of ALA and other standardistas, the IE7 upgrade smelled like victory, with future triumphs all but certain to follow. But inside Microsoft, apparently, the damage to skrillions of badly authored websites was not considered an acceptable casualty of progress. If Microsoft’s IE team was to stay employed and continue to improve the browser’s standards compliance, a new way would have to be found to protect the work of unenlightened developers.
“We can’t break the web” became the mantra. (I know this because, at a recent conference dinner, I was seated near some Microsoft people who kept saying it.)
Absurd but correct: the opt-in default#section4
The DOCTYPE switch once allowed browser makers to properly support standards-based design while not “breaking” ineptly authored sites. But as The Web Standards Project’s Aaron Gustafson explained in Issue No. 251, the presence of a complete DOCTYPE in the head of an (X)HTML document no longer reliably indicates that the developer knew what she was doing and the page should be rendered in standards mode.
Firefox, Opera, and Safari don’t have a problem with this—not because they are morally superior to their Redmond-based competitor, but because there are almost no unenlightened developers out there crafting sites to the known quirks of Firefox, Opera, and Safari. Likewise, nobody codes to the non-standard scripting languages Firefox, Opera, and Safari support—because Firefox, Opera, and Safari support standard JavaScript/ECMAScript, period.
By contrast, zillions of people who don’t know any better do tailor sites to the quirks of IE6. That’s why an improved IE7 “broke” old sites. And it’s why, in crafting a new switch, Microsoft must build its default to protect unenlightened developers. This is how they arrived at the seeming absurdity that IE42 will act like IE7 unless a knowledgeable developer deliberately overrides this default behavior by inserting an optional meta element into the head of the document (or using an HTTP header and leaving their markup pure).
It has to work that way or it doesn’t work at all—as absurd as it sounds and as nuts as it drives Jeremy Keith and many other sensible web designers. (And as nuts as it drove me for the first seven hours after I heard of it.)
If IE8 acts like IE8 by default, then IE8 might break group two’s websites (and not just break them in quotes: we’re talking about scripting, here). Breaking millions of sites is unacceptable to Microsoft’s brass and to the creators of those websites. It’s to prevent that breakage that Microsoft’s browser developers came up with the new switch. To do its job, the new switch must work the same way the DOCTYPE switch originally worked: namely, it is activated when knowledgeable developers opt in; otherwise it is off by default.
With DOCTYPE switching, “off by default” means “in (non-standards) quirks mode.” With version targeting it means “the same way IE7 rendered this content.” The behavior is the same in both cases: if you want improved rendering, you opt in.
Is this switch really necessary?#section5
You may question the idea that the new switch, which would have eased the transition to IE7, will be needed in future versions of IE, since the tough part of the transition to greater standards compliance has already taken place. And this is true where CSS is concerned. For the most part, any site that renders acceptably in IE7 ought not to “break” in IE8.
Of course, one can never be sure with hypotheticals; even if scripting were not an issue, it’s possible that any new version of IE would break something, and that version targeting is a timelessly swell idea on the grounds that it offers a mechanism to prevent breakage for any reason. It’s nevertheless true that, for many CSS-oriented web designers, the case for creating a new switch now seems less urgent than it would have been just prior to the introduction of IE7.
Still, even if version targeting were merely the tribute Microsoft’s browser engineers had to pay their corporate overlords to retain permission to keep improving IE’s standards compliance, what would be the harm? The meta element is valid, and its use is optional. The HTTP header is easy, and leaves your markup pure.
Improved JavaScript requires an opt-in#section6
But version targeting is not being introduced just to protect unskilled and semi-skilled designers from the incremental CSS advancements that will be offered in IE8. For IE8 promises to overhaul its DOM support (really getting it right) and to jettison conflicting JScript. For standards-based unobtrusive JavaScripters, this is awesome. But many coders and millions of non-standard IE-only sites aren’t ready for it. These coders and sites need the protection of a switch.
Questions? You, in the front row:
“Once again, we’re being asked to make special accommodations for Microsoft. Why can’t this annoying company get their browser’s standards compliance to be as accurate as Firefox’s? Why do they put the onus on developers?”
One accommodates Microsoft as one’s ancestors accommodated Imperial Rome. As a wiser man than me said, “Render unto Caesar.”
And actually, Mozilla has offered opt-in version targeting, first when Firefox 1.5 introduced support for JavaScript 1.6, and later, when Firefox 2.0 did the same for JavaScript 1.7. In both cases, you had to explicitly opt in. The comparison is Mozilla’s favor, for they targeted scripting language versions, not browser versions. But although Mozilla did it more cleanly, both browser makers offered targeting, and for the same reason: to protect developers from unintended behavior as their browsers’ scripting support improved.
Non-standardistas have been writing JScript for years. While the CSS changes in IE7 may have “broken” a site’s layout, IE8’s JavaScript improvements could easily render a site useless. Real DOM support is a game changer. Enabled by default, it would bring many sites to their knees. That would break the web, and not in quotes. Providing IE8’s greater compliance on an opt-in basis is the only way to get everyone over the scripting hump.
But while the opt-in protects old-fashioned coders from a major change in the scripting environment, it also offers unique benefits to even the most die-hard standardista.
The onus is no longer on the developer#section7
What’s really new is that by opting out of Microsoft’s version targeting (by not including the optional HTTP header or meta element), you get to skip testing in future versions of IE. If your site works in IE7 today, it will work in IE47, or so Microsoft has promised. It will work in IE47 even if IE47 is a bleeding disaster from a standards point of view. So long as IE47 properly supports version targeting’s default setting, your site will work just as well in IE47 as it does in IE7.
That is the very definition of forward compatibility, although it is not the route I expected us to take when I coined the phrase “forward compatibility” while formulating the benefits of standards-based design.
Flip to the other side of the coin and here’s what you see:
The system is opt-in. It’s our choice whether or not to include the optional meta element (or HTTP header) that triggers version targeting. Therefore, in fact, developers are no longer being asked to accommodate Microsoft—at least not beyond the known blemishes of IE7. Instead, Microsoft has committed to accommodating us.
This is a huge change and a benefit to anyone who has struggled to get their standards-based work to look or behave right in IE. Today’s IE is light years more compliant than the old versions we struggled with. And Microsoft has promised to improve compliance forever. If we opt in, we can expect the same level of scripting support in IE that we get from the browsers we love. Improved, predictable standards support in all browsers. Isn’t that what we all want?
At the same time, Microsoft is providing a mechanism whereby no designer or developer will ever again be surprised by a new IE version that behaves unexpectedly. If I permanently opt out of version targeting, I will never have to learn another IE quirk or workaround. That’s probably not what my agency or I would do, but it’s a viable option. (And if enough of us did it, Internet Explorer would gradually lose market share, which would make some people happy.)
If I opt in on my staging server, I can test old sites in new IE versions by adding a meta element. If the old sites don’t work, I remove the element—and to my client, the old site works great in a new browser.
Designers and developers should be popping corks, hugging each other, and weeping with joy. IE no longer sucks. Cross-browser unobtrusive scripting, with no extra work for IE (save the “work” of including a meta element or HTTP header), will soon be a reality. No version of IE will ever again surprise us with unexpected displays or behavior.
The blue pill#section8
Version targeting is a mind-bender. It shakes our browser-agnostic faith. Its default behavior, although beneficial to skilled and unskilled developers alike, runs counter to our expectations, and seems wrong. And it presents at least one Sphinxian riddle: namely, how can IE8 pass Acid 2 if IE8 behaves as IE7 by default? You can spend weeks on that one and not come up with a logical answer. Call me Lewis Carroll, but I’m okay with it.
Aaron Gustafson contributed to this article.
On one side I can see the logic in the argument for the included META tag, those of us whom already use conditional formatting to serve up IE-specific stylesheets should have no problem adding a standards-compliant meta tag to serve up our sites in IE8+ standards goodness. However, I seriously doubt that with all of the advances yet to come to the web – HTML 5, CSS 3, JavaScript 2, etc – the IE team can continue to create newer versions of IE that continue to “break” sites like its 2007 from now until their browser draws its final breath.
The real solution to this problem is to have Microsoft stop developing IE as an integrated part of the OS and break it out as a separate application so that backwards companies that didn’t heed warnings of developing IE-specific sites and intranets can continue to use the old browser with glee, while the rest of the word can continue their march towards standards compliance without the need for extra markup. Of course, Microsoft won’t ever deliver that solution – at least not here in the states – so I guess we’ll have to swallow that big blue pill for the short term while continuing to subvert IE’s install base with our recommendations of Firefox over Redmond’s mess.
And that is what this “solution” does for IE, makes that browser once again a giant mess.
The problem here is in the browser, not in the code. So why are we trying being forced to work with a code-based solution?
Doesn’t it make the most sense for future versions of Internet Explorer to have a “legacy rendering” mode available by application option to whitelist certain sites to use the IE7 engine while letting all other sites work in IE>7?
That way, since Intranets are the excuse-dujour, IT departments can roll out an additional .msi along with IE8 that automatically sets their intranet to use legacy rendering.
Bottom line: leave the decision to the viewer, not the developer.
Zeldman: “Improved, predictable standards support in all browsers. Isn’t that what we all want?”
Is that what we are getting? No. For as long as the IE7 rendering is a default rendering in IE, we don’t have improved standards support in all browsers. We’d have standards support in Firefox, Opera and Safari, but IE7 rendering in Internet Explorer.
So it comes to public light today, rather than last month, that the major reason behind version switching is Scripting and a proper Dom implementation.
It’s astonishing that two members of the Dom Scripting Task Force who collaborated with Microsoft on this, and were very vocal about their support of version switching, and overly critical of any opposition, both failed to mention the major reason behind the switch was Dom Scripting.
Onto the main point:
Given a page containing a version switch that says “IE8 super standards mode pretty please” and then contains code which conforms to the IE8 DOM implementation. Now, what is going to happen when someone with IE7 visits the page?
It will be broken.
That means, the written JavaScript still needs to support IE7. So there’s no value in supporting IE8’s DOM if you want a website that works for your visitors.
I read your promises and eloquence, and they are worthless. Microsoft’s approach forces us to support IE7 permanently – version switching does not alleviate that.
We are stuck supporting IE7 permanently – that is not what we want. Where’s the roadmap from Microsoft that shows when we can stop supporting IE7?
It is just an extra cost to my clients.
*I need to make a living, no matter how much I love the world that we want*.
If “Standards” is right (I personally believe it is), then no commercial force on earth will keep “Standards” from prevailing. *Some day it will be in MS’s interest to be compliant rather than un-cooperative*. Clearly they do not think that day is at hand.
It really does hurt a little to say it, but until that day (likely past my coding days) I have no choice. If I want to earn a living, I will code whatever hacks are necessary to make my pages work as well as I can, in whatever browser(s) my clients demand. I am sure there will be a best practice or practices, documented here, for living with this ‘bad thing’.
_It is unfortunate that my clients will bear the cost of the hacks – somebody has to – as I said, I gotta make a living._
I’m not overly fussed about the actual IE 8 decision (it’s a _fait accompli_ & according to Molly we’re lucky to even know about it!), it could be better, it could be worse, but I certainly hope discussion about the issues involved continues (maybe without all the yelling in reponse, though) because I still think there are interesting things to explore.
The general reaction in the community has been… fascinating. A lot of well thought out blog posts, a lot of very angry comments, and a lot inbetween. The almost-adolescent web, I guess.
I think Mr Zeldman, Mr Meyers etc have been sort of stuck appearing to sell a rather stinky sandwich to the masses, rather than the conduit of righteous outrage, and thus have copped it unfairly in the process.
A few random points if I may:
– I wonder if Dead Edwards IE7 & IE8 script, now hosted at (and hot-linkable from) Google, gives us a bit of an ‘out’ of supporting IE6/7 rendering quirks for ever and a day (assuming the performance has improved now they’re in beta)?
– IE 9/10/11 could still, in some horror scenario, be ‘outlooked’ ala Outlook 2007, which took a few big leaps backwards in standards compatibility when they adopted the Word HTML rendering engine, as I found out working on the Email Standards Project site. That was again done in the name of a business decision. Sure, there are good, standards-aware developers working on IE now, but who knows what decision middle-management will take in 5 years time? Or next year? It happened to Outlook last year – it’s not such an out there hypothetical. Who knows I guess, in any case, we certainly need to remain vigilant, and on friendly terms with all vendors.
– What long term effect do we think the IE7 freeze will have on future IE adoption rates? I’ve always thought there was a tacit agreement between users and developers that users should try and stay ‘up to date’, developers would reasonably support them while pushing the boundaries a bit, and we all lumbered forward haphazardly together. It seems the IE7 freeze, which seems to be for the sake of big corporations, will remove a lot of incentive for general users to upgrade, which is a shame. Perhaps a lot of the angst out there has been this realisation that the dream of universal standards support is dead, at least for a few browser generations to come. It could also quite easily go backwards, as per the Outlook 2007 debacle.
– On adoption rates, Flash is an interesting case study. Macromedia (crediting Adobe doesn’t seem fair) seems to have done brilliantly getting Flash versions out there with extremely high uptake (and they’re all backwards compatible aren’t they? Or not?), so it doesn’t seem that, in the long term, Flash-like adoption rates are really unreasonable to expect from a major corporation. Imagine if IE’s rendering/scripting engine was a Flash-like plug in, which could be pushed out to all (future) IE’s from here to who-knows-when. (No I don’t mean we should all run to Flash 🙂
– I think what would be great, albeit extremely unlikely, is if MS allowed the community the room to innovate and do the work they aren’t prepared to do. Dean Edwards scripts are a good example. Just imagine if all the hot air (irony of my contribution noted) could be harnessed into productive work on a community-developed solution, like solar energy can be harnessed to drive steam turbines.
Anyway, if IE8 is what it is, we need to start thinking what we’re going to petition MS for in IE 9.
IE8 is < 6 months away, and IE 9 is probably 18-24 months to follow, so maybe while we're all up in arms it would be a good time to get people thinking about the long term future - or even just the version after never - of IE?
Version after *next*, sorry 🙂
I really don’t understand all the people who are simply taking this lying down! I understand that microsoft seem to have made their mind up, and I understand their reasons for taking this path. But as an expert you don’t have to accept it this early, while it is still in development.
I know you say this simply accepting the inevitable, but there is a huge difference between grudgingly-accepting and preaching to the masses, book in hand, that this is the best way forward!
If other experts such as yourself were to tell the likes of Gustafson and microsoft, “whoa! slow down there cowboy.” I don’t think having quirks by default is such a good idea, I’m sure they’d have at least some doubt in their mind. Which in turn may get them to reconsider after the developer backlash when the public beta is released.
rgds
“My take on this whole IE8 meta malarky”:http://blog.vftw.com/view/browsers/ie8-taking-quirks-and-hacks-into-the-future/
@Mike Davies
bq. Given a page containing a version switch that says “IE8 super standards mode pretty please”? and then contains code which conforms to the IE8 DOM implementation. Now, what is going to happen when someone with IE7 visits the page? It will be broken. That means, the written JavaScript still needs to support IE7. So there’s no value in supporting IE8’s DOM if you want a website that works for your visitors.
It’s not as bad as that – and there’s no way round the problem as you’ve posed it.
You write your script to work in modern browsers, and you put in the meta tag or http header to ensure that IE8 knows what to do with it.
_If_ visitors using IE7 make up a significant proportion of your user-base, and _if_ the script you use doesn’t work on IE7, you _may_ choose to write a “new” script for IE7, and apply it with conditional comments so that only IE7 will use it.
But you’d have to do that anyway. Given that IE7 has a defective DOM, and we want IE8 to have a correct DOM, whatever method IE8 uses to handle old code (or even if it didn’t bother), you would _always_ have to write separate scripts for IE7 if you wanted your site to work for users with IE7.
@Luke Stevens
bq. What long term effect do we think the IE7 freeze will have on future IE adoption rates? I’ve always thought there was a tacit agreement between users and developers that users should try and stay “˜up to date’, developers would reasonably support them while pushing the boundaries a bit, and we all lumbered forward haphazardly together. It seems the IE7 freeze, which seems to be for the sake of big corporations, will remove a lot of incentive for general users to upgrade, which is a shame.
I don’t see this as a problem.
I have had features on my website that IE6 can’t access for years. Before IE7 was even in alpha. People using other browsers could mostly make use of them, and people who started using IE7 could. People with IE6 lost out on some of the finesse, but the site essentially still worked – but there were benefits to them upgrading to IE7.
That process will continue. Once HTML5 has been stamped, I will change the @doctype@ on all pages to HTML5. I’ll continue to add new features as and when I find a use for them, people with cutting-edge browsers will benefit, and people with IE7 will miss out. That’s nothing new, and won’t change now.
Any web developers who are using features supported by IE8 are likely to add the meta tag, http header or doctype to enable IE8-users to benefit. The sites that render in IE7-by-default mode won’t, by and large, have anything much beyond what IE7 can cope with.
There will still be reasons to upgrade, and people will continue to upgrade. Web authors will continue to put notices on their websites informing the user that they’ve got an out-of-date browser. Opera will pick up more users who’ve got used to using it on their mobile devices.
Zeldy sounds exactly like the webstandardsproject.org – submissive and has completely given up. Well if that’s the way the Zeld-master feels, why bother with standards at all? ‘Oh – there is a good business case for MS to piss on standards…” Well now there is also a frigging good business case to for everyone else to as well…
Standards are what is good for society and web development right? F_ck compromise. Would MS compromise for us? Not Likely. Stop acting like MS is some kind of mindless feature of the web landscape – they have smart good people that can make smart good decisions for everyone – they are just being c*nts – stop condoning it.
If MS have this target behaviour included in the next standard, then cool. It’s good. But please don’t just roll over and submit to their second rate contribution to the web society. Make them do US the favour for a friggin change. This is what I want for the web and I thought this is what Zelds wanted for it as well.
As mentioned in this article, Microsoft’s main justification for version targeting is to avoid “breaking the web”. I find their altruistic concern over this matter more than a little ironic and very hypocritical.
If Microsoft was really that concerned with not breaking the web, then why aren’t they more concerned with not breaking the desktop? Anyone who’s upgraded to Windows Vista is familiar with the problem of incompatible applications and drivers that worked perfectly fine in Windows XP but for whatever reason don’t work right in Vista because of Vista’s “improvements”. In addition, in a few short weeks, Vista SP1 will be released to the masses and we’re already being warned about problems and incompatibilities with this upgrade. How many things that work fine in Vista right now won’t work after the SP1 upgrade?
Here’s another example: I’ve got Office 2007 installed on my Vista machine. But I can’t use Outlook 2007 to connect to my work’s old Exchange 5.5 Server because Outlook 2007 effectively “broke” backwards compatibility with this version of Exchange server. If Microsoft is so worried about not breaking the web, why are they so willing to break the desktop?
Anyone who’s worked with computers for a while accepts the fact that you can’t maintain backwards compatibility forever. At some point, you have to sacrifice backwards compatibility for improvements and innovation. As they say, you can’t have your cake and eat it too.
I would like to see Microsoft step up to the plate and accept full responsibility for this mess. The problem really isn’t “unenlightened” web developers or poorly written web authoring tools. Sure these factors have contributed to the problem, but the real heart of the problem is Microsoft’s crappy browser. Had IE had better standards support right from the beginning, there would be no such thing as unenlightened developers or bad authoring tools because these people were just follow Microsoft’s lead.
But for whatever reason, all I’m seeing is Microsoft trying to shift the blame off of themselves and offering yet another lame patch in an attempt to cover up the issue while mindlessly repeating their hypocritical mantra of “don’t break the web”. Microsoft, unfortunately you already broke the web a long time ago! It’s time that you accept this fact and start fixing it for good.
Why can’t it be opt-out by default? If there are sites that are advanced enough to be using all the stuff that will supposedly break, they are presumably ones that are being maintained – so why can’t those just have to opt-in to old behaviour. That way it’s clear that they have work to do to fix things.
…why not have this version targeting stuff for the Javascript engine only? After learning about Microsoft’s transition from JScript to Javascript (hooray!) version targeting makes more sense. But why not limit it to the Javascript? Have one of those appendages to the MIME type declaration like Firefox does, or some funky IE-readable comment in the script file itself, or an HTTP header.
As others have already said, given how big a change there was going to IE7, how much breakage is there really going to be in IE8, in terms of layout?
This switch gives bad [or should I say ‘evil’ ;-)] developers a tool to keep selling their broken code to ignorant customers, who pay large amounts of money for websites that they think will reach as many people as possible.
If MS really cares about website owners they would not provide such tool.
Kudos to the Z-Man for talking sense.
I cut my eyeteeth in web development in just such an atmosphere as Zeldman describes: a large public-service agency that, at the time was transitioning from IE5.5 to 6 as the only browser employees were permitted to use. Without naming the agency by name, I can tell you that if those employees can’t do their work because of a browser screw-up, the trains and buses in New York City might not run on time or at all, in some cases.
This is serious stuff folks, and Microsoft is doing the responsible thing, that’s all.
The only thing we can do is change accordingly.
The argument in this article make more sense than Jeremy Keith’s article; I think. It would also seem that Jeremy would benefit from reading this article, as Jeremy has almost had me convinced his argument was the right one, before I read Zeldman’s.
I know plenty of people have posted their own statements of agreement or opposition, and their own solutions to Version Targeting, but I would appreciate your opinion on “my idea”:http://www.digitalgemstones.com/blog/entry/13 which to summarize is version targeting where the default is one version behind the current. This would give developers a padding of a few years to update their code, while still encouraging standards to grow and improve.
I don’t really see a reason why IE42 would act like IE7. I suspect that the default rendering will eventually move forward to accommodate the market.
A few points:
1) Amateur developers are often only concerned about something looking right. If IE continues to default to quarks mode, these amateurs are going to think their broken code is actually correct. There is no feedback for them to clue them into the fact that they are doing something wrong. Clearly this is not the way things should happen.
2) If someone is dependent on a site that only works in IEx what is to keep them from using IEx? Couldn’t Microsoft just allow people to install whatever version of IE they want (independent of OS) and solve the problem?
3) What’s wrong with asking that sites that rely on old versions of IE from altering their code to note what version they are requiring? If you are a corporation using an IE only internal website, how hard would it be to add such a tag? Having worked on such a site, the answer in my case would have been “not very hard at all”.
4) There is something completely silly about requiring a designer to opt-in to standards mode. Is it really too much to ask that the standard should be. . . the standard?
5) I agree with others that suggest IE include a legacy mode. They do this in Windows where you can tell the OS that a program is from Windows 95 or 98 or whatever. It would make sense to allow users to say “oh this site is broken, let’s try a legacy mode”.
6) Overall I just think we need to favor standards and current state of the art over deprecated and legacy code. I think Microsoft is right to want to accommodate older code, but they shouldn’t require everyone to make this accommodation. Microsoft and the users/administrators of these legacy sites should bear the burden.
then we have to do the following …
– FCC can not go to a digital television broadcasting. Frankly this move will not allow me to see my TV shows with all the hazy and ghosting I have gotten use to. Not to mention all those poor pirate TV stations out there.
Sometimes it is just necessary to bite the bullet and move forward (analog TV, Betamax, 8-trax, tapes, HD-DVD). Microsoft backed the wronge horse (themselves) and lost, suck it up and move on. (add more cliche sayings here)
After getting all these famous people here at ALA to agree (well, some at least), Microsoft now tells us (or so I understand) that they were wrong:
“http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx”:url
I’m glad. But why did all the famous, well respected people not tell them straight away that this should be the way to go? Why did they, at least this time, no stick to asking for respecting standards?
I’m not understanding how this is different from the problem that overtook the old DOCTYPE solution… What if something like Dreamweaver or FrontPage or some other future web site development software decides to “help” the user by inserting this meta tag — doesn’t that mean we end up in exactly the same place in the end? That is, is it not still possible we may end up not being able to assume the meta tag actually means what it says it means?
Well is it, Jeffrey? And all the rest of you who felt that if it was ok with Jeffrey then it must be ok with you? Well it wasn’t OK. And others (especially those on a different continent – there are other continents you know) defended web standards against Microsoft. So, like spam in the EU, it looks as if you will have to opt in for IE7 compatibility. Next time, just say No.
If doctype switching is not a reliable method for indicating whether a developer has built their site to be standards compliant or not, then who says that version targeting will be any better. What is to stop uninformed developers from targeting standards based rendering but not actually using it in their code – thus breaking their sites just as uninformed developers who used the strict doctype but didn’t build their sites accordingly saw them break in IE7.
Just to reiterate, from the IE blog (linked to above):
So that leaves us where we started. But, although I would not have minded nailing down pages to a version of IE (since we already often have to add IE if-statements), I dislike the idea of having to add special code for any browser, search engine or anything else. That said, as browsers are released (and we’re talking years and years here), there *will* be display problems for older sites.
To some extent, I agree with the article. However, I think that version targeting is, though a great solution on short-term basis, not feasible on the long-term.
# First of all, let us examine the fact that there are lots of developers/designers out there who sort of fall in between the two groups of knowledgeable designers and ‘unenlightened’. I’ve been one for years myself.
Imagine being an intermediately skilled web designer. You’ve heard of CSS and try to implement it in a standards-based way to the best of your knowledge, but your main goal is to make a cross-browser compatible website. How can you be expected to know of the “X-UA-compatible” switch and how to implement it? In fact, I only recently found out about the “almost standards” mode in browsers, and had believed all my pages to be running in strict mode for years, even though this wasn’t true for some of them. As an intermediate web designer, you can’t be expected to read ALA on a regular basis. The problem with the version targeting is that it doesn’t accommodate the users *_in between_* the ‘two groups’. This opt-in behaviour will give millions of people, professionals and hobbyists alike, severe headaches while they’re trying to figure out why even the newest Internet Explorer won’t look like Firefox and Opera. Or worse – why Firefox and Opera won’t look like the newest Internet Explorer.
# Then, there is the long-term feasibility of this switch. I think it is unrealistic to have IE42 behave like IE7, because before long people – yes, even the unenlightened – will start to take notice of this behaviour (especially since IE is loosing market share by about 5 % a year, “source”:http://marketshare.hitslink.com/report.aspx?qprid=1&qpdt=1&qpct=4&qptimeframe=M&qpsp=91&qpnp=25 ).
Now, “Quirks Mode 2.0” might be just displaying pages differently, but if “Quirks Mode 2.0” _really_ behaves like IE7, it could, in the future, also mean not supporting new features, which will start to become very noticeable at the time IE9 or IE10 is released.
And how will we know that this is the last ‘switch’ Microsoft is ever going to come up with? I’m not quite convinced.
# And now, about web standards. Though version targeting is presented as a feature advocating standards based design, I think this is not the right thinking of Microsoft. Surely the knowledgeable developers who already embrace web standards will continue embracing web standards, but implementing this switch will never bring web standards to the masses. In fact, it will throw up yet another barrier, and probably not the last.
# Ironically, the web sites that will actually “break” to a catastrophic extent – e.g. illegible or unusable – are probably the web sites authored by the knowledgeable designers anyway, who know of the X-UA-compatible switch and how to implement it. It kind of beats the purpose, doesn’t it?
# Now, please consider this: “Breaking the web” will _never_, _ever_, be a more shocking user experience than the transition to Firefox, iCab, Safari, Opera, the Wii Browser, the iPhone browser, etc. A transition which is usually not really that noticeable at all – at least in my experience. The only web site that won’t work in my beloved Firefox is the **** Microsoft Update… Just to make a point.
Now, one might argue that “…zillions of people who don’t know any better do tailor sites to the quirks of IE6,” and that “That’s why an improved IE7 “broke”? old sites.”
From this I gather that websites are “breaking” more severely in IE7 than in Firefox or Safari because web designers are using workarounds such as CSS filters, the holly hack, and conditional comments (in fact a form of version targeting itself) to code for the quirks of IE6. Maybe I’ve misunderstood, but I think the correct solution to this problem would be making IE8 so that it would behave *_exactly_* as other standards compliant browsers – removing support for the Holly Hack, conditional comments, etc.
Freezing the web might just not be the smartest thing to do. Especially since Microsoft hardly makes the rules anymore. I would be interested to hear what the W3 Consortium has to say about the matter. Maybe they can offer a better solution.
I have downloaded the Beta of IE8 and I am not really that impressed. It breaks an amazing scrolling javascript function on my company’s homepage. Does this mean a new set of hacks for IE8? I did like the reference “We might call them the unenlightened” in the article.
We are microsoft. We are the standards. Resistance is futile. You will be assimilated.
Every time I read an article about Internet Explorer those words go through my head.
It’s basically all promises and only 20% of those promises get delivered.
I think microsoft is still in brand loyalty mode and that will never change.
Who created all these hack web-masters in the first place? Netscape was bundled with windows not that many years ago only 15.
They do know they can brand firefox right?
The only way to have standards compliant web developers is to have a standards compliant web browser, even if joe newguy is just starting to learn building webpages if something breaks they will learn standards.
For those who call themselves developers and don’t follow the standards then hey let their websites break, it their own fault anyway. Maybe they will thank Microsoft for helping them code better.
It’s best for their bottom line to follow these standards.
If they don’t you can always add this line to your website
“Best viewed on a good Web Browser” with links to opera, firefox, etc..