However the idea that adding a meta tag to the head of my documents now and for the unknown future is absurd, the http header doesn’t help much either, it simply creates a barrier that I constantly have to move forward as IE gets its act together moving forward (yeah well, read on).

My first fear is simple, this is a hack, there is no way you can look at this as anything other than a hack (designed for one purpose, and that’s not to help transition), the biggest problem with a hack like this is the ability for that hack to be abused (we’ve seen it with every form of hack to bring a browser into compliance). The abuse though not malicious by nature, will more often than not be implemented by those that don’t know better, and what is the forecasted impact of that type of abuse? In 10 years we are going to be right back where we started… 70% of the web coded for 2001 30% for 2018 (depending on how many people will learn the meaning of this meta tag, let alone a doctype).

I’ll leave you to ponder that…

My second but most important fear is even simpler, while it seems like Microsoft are trying to make a transition to standards easier (like transitional didn’t give them enough time) they are in the best position out of all the bad eggs to abuse the use of this meta tag. I personally believe the IE dev team want to do right, but there is no way in the world anyone can convince me that MS management are not pulling the strings here. This is not a debate about standards or the preservation of digital content from yesteryear (why can’t I open my old word docs in the latest version?), this is a debate about “open web” vs “MS web”, if they really care about the preservation of old web pages this would be a non issue and we wouldn’t even hear about this insane meta tag.

I think one point that has been overlooked here is the fact that their very own OS help file system is still based on antiquated technology (the same tech they are trying to maintain support for), if they switch to standards they break their own OS (as well as the BIG client interests mentioned elsewhere), this is not about us, this is about them, its time we all stand behind each other and grow some teeth, we have reached the tipping point and to buckle to their demands would negate 10 years of hard work.

No matter which way this story is twisted it will always have the same ending if MS get their way, and I guarantee it won’t be “and the developers/users lived happily ever after” no, it will be more like “and Microsoft lived happily until the market caught up again”.

Stall progress, crush competition… Its blatantly obvious what’s happening here. Think it over.

Cheers!

I think that meets Microsoft’s demand for opt-in. My site would not break as IE8 rolls out (assuming Microsoft does its emulation correctly). It could only break when I change the HTTP header from ie=7 to ie=8 and who do you think will get the blame if that happens? And if someone really wants to create a document for archival that won’t change over time, they can use the meta ie=7 in those specific documents to override the server setting. Though I think it would be better if Microsoft would document and get its own DOCTYPE for something like this but I’m no document standards expert.

As for web developers, just continue to write to the standards and just use meta to temporarily override the server default in specific broken cases or for archival. As long as I, as the server admin, keep increasing the HTTP header to keep up with IE releases, we keep the web site running with the latest standards. Isn’t that what the web developers want?

It is a shame Microsoft didn’t solicit more feedback or think this through more thoroughly. They could do something like ie=+7,-8.0,+8.1 to mean ie7 should render with ie7, ie8.0 should also render with ie7 (presumably because bugs are found in ie8.0), and ie8.1 should use the 8.1 rendering. That way Microsoft could implement quick bug fixes in IE8 until they declare it stable. Since the only way to get the IE8 rendering is to opt-in, you either wait to opt-in until it is stable or your opt-in to an unstable version means that you are prepared to opt back out of IE8 or fix the documents if a bugfix breaks your web site.

Before I address that, though, I need to say something about the persistent characterization (by many people) that the breaking of web site by updating browsers is a “myth”. For it to be a myth, I would have to be lying about my experience at Netscape. As would the people on the IE team who nearly lost their jobs over the breakage between IE6 and IE7.

We can disagree on the degree to which this breakage is a problem, but to wave away the issue as “a myth” is not at all helpful and frankly somewhat insulting. If that’s where we part ways on this, then fine; don’t bother to read on, because none of it makes sense if you insist it’s based on a “myth”.

Now back to the main point. As you said:

If the biggest gorilla in the room doesn”t care about standards, why should anyone else?

Here’s what I foresee happening in the IE world without version targeting or something like it:

“Hey, we need to fix this bug in order to enhance and add these other things.”

“Will fixing it break existing sites?”

“Probably a few, but they’re old and–”

“No.”

…and so the forward momentum of standards adoption in IE slowly (or possibly quickly) grinds to a halt. And if the biggest gorilla in the room stops pushing standards forward, why would anyone else bother?

Even if all the other browsers did continue to push forward with their standards support, what good would that do? Authors aren’t going to use, say, advanced CSS layout if IE doesn’t support it in any form. We then have to either wait for IE to completely die out in the user base, or else wait for something to replace the web altogether.

With version targeting or something like it, I foresee the following variant of the above hypothetical conversation:

“Hey, we need to fix this bug in order to enhance and add these other things.”

“Will fixing it break existing sites?”

“No.”

“Go for it.”

In that scenario, there is the hope of luring more and more developers forward to make use of the advanced features in IE8 and beyond. And who knows? That might even be the vector along which more awareness of standards can finally be spread.

At any rate, I guess we can agree on at least one thing: I’ve wasted a lot of words. I don’t think we’re talking about the same words, though; or, if we are, then the type of waste is likely very different.

On the other hand, if your assessment of my advocacy being wasted hinges entirely on my wanting to freeze the most used browser at a non-compliant level, then hallelujah, I’m redeemed: I’ve said time and again, over and over, in multiple ways and places that I want the default behavior to be “latest”. I have argued that they should take that approach and use the IE8 beta period to get word to those who don’t want to fix their sites that a “one-line fix” will keep their sites from being disrupted.

But I also am able to look at the situation as it is and understand why that might not be an acceptable choice for the IE team—and also to see that to at least some extent, my preference is driven by a selfish desire to push the meta tag addition onto others, instead of having to do it myself. That’s not the whole of my rationale, but I would be dishonest to myself if I didn’t recognize that it’s there.

As for the site that mainly drove “almost standards”, it certainly has been redesigned since then. Unfortunately, their markup practices really haven’t advanced much; now they have fewer layout tables containing lots of nested divs and even a few spacer GIFs. I honestly can’t tell by reading the source if their current layout would be broken outside of quirks mode or not. But let’s remember, there were multiple sites causing the problem, IBM’s among them, not just that one site.

Anyway, I need to stop now. I can but hope that at least a few of these words were not wasted.

Now, an opportunity arrives which will result in the browser with the largest market share continuing with a default behavior that is not standards compliant. The unintended consequence I see is not in ensuring all the broken web pages still render well, but in encouraging the everlasting continuation of non-standard coding.

Zeldman laments not being able to reach more developers, not being able to persuade everyone toward standards. Well, how is this going to help? It will perpetuate IE’s bad behavior, as well as most developers’ bad behavior (much of which we think is unintentional non awarness of standards). Where is any incentive to move to standards? None, gone, nada! If the biggest gorilla in the room doesn’t care about standards, why should anyone else? All of those developers Zeldman worried about not reaching still won’t be reached. They won’t code to the standards compliant features of IE8, 9, 10. They’ll code to the (frozen) base, just as they coded to IE6. Sure, the results will be marginally better, but definitely not standards compliant.

If you think that it’s OK to freeze the most used browser at a non-standards compliant level, and by that action to encourage people to code to that level, it turns your standards advocacy into a lot of wasted words.

The place where I think things went awry was buying into the idea of “breaking the web.” This is the fundamental assumption justifying the pragmatic solution, and I believe the assumption is a myth. As I mentioned earlier, the stuff that really matters will get revised sooner or later anyway, and when it gets revised will be updated to work with the latest browsers … assuming they aren’t frozen.

Out of curiosity, did the site which led to the creation of “almost standards mode” ever get revised after that incident? If so, did the revision negate the need for “almost standards mode?”

In the end, I”m disappointed that two of the people I admire, Eric and Zeldman, have been overcome by mythical rationale and have stepped away from their core beliefs.

This is something I (both of us) have been accused of over and over again in the past couple of weeks, and I guess now’s finally the time to ask: exactly what core beliefs am I supposed to have abandoned? Since I’m not aware of having done any such thing, someone else is going to have to enlighten me.

[Fixed. -E]

My bottom line is disagreement with the proposal, for precisely all the reasons Eric stated in the ALA article, … before he justified the so called pragmatic approach. I believe we should keep moving forward and not support any browser having a default behavior that is not standards compliant.

My viewpoint is a bit different than I’ve read in any of the comments. Free market economics are my guiding principles. At the simplest level, if a product fails to meet its customers’ needs, the producer has two choices. Make what customers want or go out of business. Stark, but it happens all of the time. I’ll come back to this shortly, after doing a little myth busting.

Two of the arguments in favor of the proposal are that “the web is broken” (or this will break it worse), and MS is listening to its Intranet customers.

First, the “broken web” is seemingly justified by the millions of pages already in existence which we must keep working as they are. In fact, Eric says,

But remember, “let old sites break” is a non-starter.

Why is that a non-starter? Many of us in this business are very well aware of how frequently sites get redesigned. With each redesign, it’s not only the presentation that changes. Almost always, redesigns are accompanied by code updates, often needed to take advantage of new features. My belief is that almost any web site that matters to someone will be updated as a matter of course some where along the way. If the site really matters, it will be updated sooner, the way people fixed problems with IE7. On the other end of the scale, if it really is just a dead site, it probably doesn’t have serious rendering problems anyway, and few will care enough to warrant updating. In essence, “Yeah, it’s broken, but no one goes there anymore.”

That puts me firmly in the camp of not caring that the web is broken. From the free market economics point of view, those pages are like the used goods we find in a flea market. They’re not relevant to mainstream consumers. Don’t waste energy on worrying about them. Let the old sites break. From the free market economics point of view, the old site is a failed product and there are always better that can take its place.

Second, the intranets. Here, my perspective is from being a developer for a corporate intranet, one that serves a very large international business machines firm. I helped move that intranet’s design to standards compliant code the last time the design was updated. Here again, designs get updated, and code with them. Yes, there are probably a fair number of intranets where some portion of their content is still old, still used, still “matters,” and breaks with IE7. And yes, there is at least one “business critical” application on the intranet I worked on which has problems with IE7. However, like most everything else, that application is scheduled for revision due to other business purposes and will get upgraded to new technology at the same time.

I haven’t heard anyone else mention the following yet, but those intranets are the real sore point for Microsoft, and the big problem is Vista! The firms who have those sorts of problems also have “managed clients” where the firm controls the software on each employee’s system. Those firms are refusing to upgrade to Vista because it breaks their intranets. Therein lies the real problem!

To me, this looks a lot more like a Vista revenue problem than Microsoft really caring about breaking the web. The broken web and the intranet problems are real, but mythical when compared to Vista not producing the expected revenue. Think about it for a few momments.

Coming back to free market economics. It is IE that is broken, not the whole web as some would have us imagine. Let the free market work, and bad products will eventually be driven out of the market.

Imagine an auto manufacturer declaring that they are going to stay with old mechanical carburetors as the default for all of their engines … and justifying that decision based on the belief that all the naive mechanics can more easily maintain carburetors than modern computer controlled fuel injection systems. How long would that idea survive? Not long, because every other auto manufacturer would launch advertising that ridicules the idea, and the marketplace would reject the product. Yes, it is a far fetched analogy, but not that far. The concept is freezing technical advancement, whether staying with obsolete carburetors or staying with a non-standards compliant browser. The biggest difference is that the browser industry, unlike the auto industry, has fewer competitors and the one wanting the freeze in the browser market has monopolistic market share.

Freezing a technical implementation is rarely a good idea. I can’t recall when it has ever worked. Why start now?

We have been moving the web forward for almost a dozen years. We haven’t been so caring about whether “the old sites break” … until now. Why the need to fix Microsoft’s problem with the regressive approach of freezing technology … and prolonging the bad behavior (coding habits) of many old school developers?

Like the products that don’t meet consumer needs, let the old sites fail. Let IE fail too. If Microsoft decides to stay with this idea, I can foresee the time when developers (first) and consumers (second) will come to see IE as a failed product and it will again lose market share to the standards compliant competitors. Rethink Microsoft’s proposal as one based on unfulfilled Vista revenue, and it’s not nearly as important as we’ve been led to believe. Keep moving forward and let market economics solve the problem.

In the end, I’m disappointed that two of the people I admire, Eric and Zeldman, have been overcome by mythical rationale and have stepped away from their core beliefs.

Disclosure: Some will be aware that the intranet I referred to was IBM’s. I recently retired from IBM after 40 years with them. My opinions expressed here are my own, not IBM’s.

The first thing Aaron said very close to a “MUST”, but his second statement, the one that sums up the idea, is more of a “MAY” or even an “OPTIONAL”. That was what I focused on, since it came later and therefore (to me) had more weight.

As for the rest, the long-term effects could be as you describe, or not; we’re all peering into our crystal balls and seeing different things. My concern is that without this or something like it, we’ll never see significant standards advances in the IE line, and thus the wider adoption of standards will be stifled for as long as IE exists as a major presence on the browser landscape.

But I’ve made that case elsewhere, and if people aren’t convinced, well, they aren’t convinced.

I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting. Not at all. Please be clear on this: nobody is saying this should be required in any browser.

but Aaron Gustafson wrote, in the original ALA piece:

…define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future.

and

This is exactly what our group decided to recommend for IE8, and we hope to see it implemented in other browsers as well.

so I’m afraid you’re wrong about that, at least, Eric. Someone definitely is proposing to push this out for all browser makers.

As for another point, yes there is a similarity between things like the “box model hack” and this. But the main difference is that when we include these twiddly bits to work around browser bugs, we (hopefully) code the rest of the site so the browsers without those bugs get it right.

It’s a subtle difference I grant you, but the impact is more significant. Because we’re looking forward with the design, and just doing a little necessary patching for the laggards. By implementing version targeting, even if it’s only IE that does it, the designer completely stops looking forward, and simply designs for the past. I think we’re losing more than I’m willing to sacrifice. You recognized it as a loss elsewhere; are you so sure it’s a loss we should accept if we don’t have to? There are other options to accomplish much the same thing, that we’re using now and which don’t have those deleterious effects.

After I wrote my own piece on the subject, I realized there was another reason not to use it as a designer: skills atrophy if not used, and once I start down the road of designing for past browsers, how far will it take me? Will time spent on that hinder my efforts to keep current? How many clients will, when hearing of this, demand designs for an older browser? What new opportunities will I miss because of that?

I’m not at all comfortable with those thoughts.