Tuesday 22 January 2008
<META HTTP-EQUIV="X-BALL-CHAIN">
The IEBlog predictably announces that Web developers will have to use a <meta> tag or HTTP header to get IE to treat a page with post-IE7 standards compliance. Obviously a lot of people are going to be upset about this. I'm actually just puzzled. I see the business argument for taking this approach in the short term, but in the long term, it seems to impose a crippling burden on IE development.
The logical way to use this tag is to ship multiple engines and use the tag to control which engine is used to render each document. You "freeze" each engine after its release, avoiding making any changes to it because each change is potentially going to regress some site. Sounds simple and appealing, but there are huge problems:
- Footprint. You're shipping a lot more code, and it grows a lot with each release. If the user browses a mix of pages, you'll actually execute a lot more code too. Good luck competing in the mobile space when you ship half a dozen engines and your competitors only need one.
- Cross-version interactions. These engines have to talk to each other. I can have a document in one mode with IFRAMEs in other modes. These documents can even touch each other's DOMs, including layout-related DOM APIs. Architecture changes in a new engine might be constrained by, or impact on, the design of earlier engine releases. This raises the question of whether the DOM implementation, JS engine and other components are actually duplicated. If they are, problems multiply, but if they aren't, you can't guarantee compatibility.
- Maintenance burden. The truth is that you can't ever actually freeze those old versions completely. If a security bug or crasher bug is found in any one of those engines, it must be fixed in each engine it occurs in. Those fixes can create compatibility problems, so your "compatibility guarantee" turns out to be a mirage. But you have successfully multiplied the cost of security fixes and testing those fixes by the number of engines you're supporting.
- Attack surface. Each engine represents exposed attack surface. Sure, there's overlap in the code so you can't just add up the vulnerabilities, but each engine adds to your attack surface.
So does Microsoft have some magic technology that alleviates these problems? Beats me. I can imagine a tool that could find common code and merge it automatically, avoiding accidental behaviour changes, but that doesn't really help much. It'll be interesting to see how it plays out.
One Aaron Gustafson says "I, for one, hope other browser vendors join Microsoft in implementing this functionality." For the reasons above, and other reasons, I seriously doubt Firefox will be interested. I'll talk more about this in a follow-up post.
Comments
So I want standards mode in Firefox, Opera, Safari, so I use the correct doctype. Now which IE engine do I want to use?
So already making those choices. Now what happens when IE9 makes changes, bugs are found in both? I want 1 rendering engine for this page, another for that page.... this is going to be amazingly complex.
It's hard enough TODAY to follow all the rendering quirks in IE, Firefox, Safari which are tier 1 browsers in most companies in terms of support. We have Firefox 2.0, and soon 3.0, same with Safari, and IE6, IE7, and soon IE8 added to that.
And we're not even talking about JS or DOM implementation, canvas support, xslt support, etc. etc. Just html rendering.
There's a reason for standards. To avoid this very problem.
I just wish the IE team would stop repeating their compatibility mantra and just rip the bandaid off already. In one motion, "right off!" as Seinfeld says.
I hear that in Internet Explorer 9, to get the most standardest standardy standards mode, you have to include a paragraph at the beginning of every file describing how awesome Microsoft is and how much you love them.
What they didn't get is that by making people fixes the problems of old website they generate better coders, and more employment options for people.
I can say for sure that I will not download the 90gig that internet explorer 15 will be ... and probably everyone
I just hope I win the lottery before IE8 is out so I can retire early and do stuff for fun that only works in FF :)
Of course, I think this whole mess is a TERRIBLE idea, but I think they could program around your holes.
---------------------------- all other vendors ?
To webdesigner who think this is great :
What the PSP/PS3 browser do the same and a version N+1 goes out? Will you buy a psp just to check if you should put PSBrowser=N+1 or ignore it (And if they do as microsoft you will have the old, buggy, version N rendering engine)
What about all versions of opera (mobile, wii, ...) ? about all the webkit builds/versions ? about the GTK html rendering code ? about IE-mobile ? about the Nokia browser ? The blackberry one ?
Their solution is broken and is tolerable by them only because they have a VERY big market share. I'm waiting for them to do the same with IE Mobile just to laugh.
---------------------------- A small tale
Today i create a website and test it fully with all the biggest browser and it's perfect. I'm using feature X but they all implement it correctly.
Tomorrow browser Y appears : it's a small engine but not used well, for my new websites i include it in my test suites, it doesn't support feature X correctly (Say X is the box model and it's implemented as old IE implementations) but it's ok : few people use it.
Browser Y implements "X-UA-Compatible" as recommended by microsoft.
A few years latter browser Y is the browser everyone want to use : It's sexy, it redefine the web, yada yada yada... And it fixed this annoying bug in the X feature long ago. But as some customers of browser Y still use the old implementation of Y, you need to specify a X-UA-Compatible info for Y to treat it correctly.
And in this immaginary future, all web sites programmed to web standards, are now either totally broken (Because everyone use Y) or need to be changed to include the correct "X-UA-Compatible".
They could do it mainly because most of the web is IE-Compliant before being Standard-Compliant AND want to be IE-Compliant before anything else.
But as said in my post except Trident and maybe Gecko it's impossible to do for any other rendering engine : No one will bother to test all their old websites again each time you do a new version.
How about Mozilla throw us web developers a bone by, once, just once EVER, being compatible with something IE does? Or at least not arbitrarily incompatible, as it has been since day 1. Even if you don't like the idea, just suck it up and try it for a few years and see how it works out instead of just dismissing it out-of-hand because "Microsoft is teh evil!!!" Seriously, it's childish, and it's sabotaging the IE team's willingness and attempt to make up for past mistakes.
Note, by the way that there are plenty of IE-compatibility things in Gecko. document.all comes to mind, as does the handling of various aspects of form control rendering, innerHTML, offset* properties, etc, etc.
Also, I don't see Robert "dismissing it out of hand." He's just citing the reasons why Gecko is not likely to do such a versioning scheme. Some of these may apply to IE, some may not. I doubt IE cares about its download size, say.
We have copied a number of IE features that Web developers needed, for example XMLHttpRequest, innerHTML and getClientRects.
Someone's being childish here but I don't think it's me.
The majority of developers do not care about standards compliance, and neither do their customers. If there was more incentive to be compliant, there would be more change. If Google was to give a slight ranking boost for standards compliant pages, you would see half the internet become compliant overnight.
Even right now, both Internet Explorer and Firefox (and Safari, and Opera) all render non-standard tag soup. They all include backwards compatibility modes. What was written for the web 13 years ago will still render in modern browsers. The fact is that every browser is *already* filled with this code.
There is no reason to assume that a browser needs to have each and every rendering engine build it. It's been done the same way for 13 years, it doesn't need to change now. But in order for Microsoft to improve IE while maintaining backwards compatibility (which they *need* to do) this seems like the *only* solution.
Everybody is perfectly happy with DOCTYPE switching, why complain about this? It's basically the same idea but instead of merely 2 levels (standard and non-standard) you can actually target the current state of the web.
For example, the behaviour of Firefox "quirks mode" actually changes from release to release, hopefully becoming less buggy over time. Our "quirks mode" is actually just a fairly small number of specified behaviour differences from "standards mode", NOT "exactly what Firefox 1.0 did" or anything like that. That is a lot less compatibility than what Microsoft says they're aiming for.
Take your pick!
Surely it's better to have the choice?
I'd rather have the choice of IE6, 7 or 8's standards implementations than still be stuck with IE6's so-called 'standards' implementation.
I agree with other issues raised about browser development bloat and attack vectors etc. However this is only for IE to worry about. There's no reason to suggest - AFAIK - that non-IE browsers have to worry about adopting this meta tag, triple+ engine/modes support.
This is merely MS trying to move forward without sacrificing their huge customers like Oracle/BEA and their shithouse IE6-centric software like Web/AquaLogic or Plumbtree - whatever the hell that crapware is called.
getWidth()
{
switch(bugmode)
{
case 5: return x;
case 6: return y;
case 7: return z;
case 8: return width;
}
}
All we need is a META tag like the following:
<meta http-equiv=”X-UA-Compatible” content=”FF=3” />
and IE will know to switch to its Firefox 3 rendering mode!
I wish I didn't have to mess around inserting a meta tag now, going from IE7 to IE8. But of course if I didn't have to insert the meta tag, then all the people who coded to IE6's bugs (and updated for IE7) would also be getting the IE8 rendering, and their pages would be as broken in IE as they are in other browsers, horrors. The good news is, with Microsoft *having* the edge option but strongly *NOT* recommending it (unlike the doctype, which they did start recommending, which is why it no longer really implies that the webmaster understands web standards), hopefully we will only have to go through this once. Microsoft will encourage everyone to say IE=8 and get the IE8 rendering, and then when IE9 comes out they will encourage everyone to say IE=9 and get the IE9 rendering, and so on, and those of us who code to standards and check IE compatibility as an afterthought can blissfully continue using the same IE=edge option, hopefully indefinitely, and always get the latest rendering engine available.
If they hadn't included it, it would have been tempting to say something like IE=65535 in an attempt to get the same effect. But that's ugly and bug-prone.
This strikes me as a decision made by a non-programmer, perhaps a well-meaning project manager. "We'll be backward compatible forever!" Um, no, you won't. You're just signing up for a boatload of complexity and problems with almost no tangible benefit.
I think calling something "standards mode" and then being upset when it renders standards correctly is a bit retarded of web devs, but I don't really blame MS for trying to do something to make their lives easier.
Truly, the IE dev team should be the first ones against the wall when the revolution comes. Morans.
No one is forced to use this. The ability to have your pages render using the most current IE=edge makes this completely optional. I personally can't wait to target my pages to the same browser I use to test them. That goes double for my clients.
What this does is allows Microsoft to pursue greater compliance with standards without breaking backwards compatibility. There are many comments here and on other sites that don't see Microsoft's commitment to backwards compatibility as important. People actually suggest Microsoft should just break all the sites and move forward. It is somewhat depressing, and fundamentally disconnected from reality.
Ultimately, I don't care if Firefox supports this specific standard. The impetus of backwards compatibility now firmly belongs to the browser. Firefox can pursue an entirely different solution. The reality is, Firefox breaking backwards compatibility doesn't cost me money, because the client never cares. They care if the next major version of IE breaks the site.
> People actually suggest Microsoft should just
> break all the sites and move forward.
Yes, I agree that's misguided. I think there might have been better ways to address their issues; for example I've argued in the past that Microsoft should have separate browsers for the public Internet and the private intranet. This would be a lot better than having multiple engines in the same browser, because for example hostile Internet pages could not request an old rendering mode in order to trigger some security bug, and you wouldn't have interacting pages that required different modes.
The problem with IE=edge is that if a lot of people use it and Microsoft fears compatibility problems with those sites in IE9, they'll make 'edge' mean 'IE8' and introduce IE=really-edge or a new META switch. We'll see.
But yeah, they'll do what they do and we'll do what we do and we'll see who wins.
I'm ok with HTML 4.0 defaulting to "IE7 version" but I'd really like HTML5 and "XHTML 1.0 Strict" to default to "Edge version".
By the way, your columns are too narrow. Having to keep jumping to the next line all the time makes reading too staggered.
If in a hypothetical situation your app only worked in FF 1.0.x, you could still use the app because you don't have to remove FF1 to use FF2 or FF3 etc. Just be sure to use separate profiles. :) And that would have no effect on the progression of the web.
And I personally won't be marking my own pages as IE Super Compatible For Now(TM) because *I can't test IE* because I'm not paying good money for Windows, just to add extra frustration to creating my personal pages.
You're right that when you implement new features, including standards-based features, you create more attack surface. Some attack surface is worth having. You want to reduce the unnecessary attack surface, however.
How is this complicated?? If you are building a page today, and you have tested it and are happy with the way it displays in the browsers you used to test the tag you would use is
Assuming that IE8 and FF3 where the browsers you tested with.. Simple.
Why is that complicated or confusing?? How can we possibly know what cool new system IE50 or FF50 will have?? Will HTML even exist then?? If there is not a way to preserve OLD pages that are not updates, then we will loose this content for ever..
but if IE50 or FF50 can load the page build 30 years earlier, and say "Oh crap! This is a really old page!! I need to render it the way we used to 30 years ago" how can that be a bad thing??
Without a solution like this, how realistic is it that a browser in 30 years from now would be able to render a page we built today (even in standards mode! - what will be standard 30 years from now?? )
The only real negative I can see in this is that browser developers would need to include different versions of rendering engines in future browsers.. could lead to (more) bloated code...
>Assuming that IE8 and FF3 where the browsers you tested with.. Simple.
But, not really that simple. What about the people who do NOT upgrade to IE8 and are still using IE6 as their browser. Just because your browser target is 8, that means the viewers of your site who are still using IE6 to render those pages require you to continue to add your "work-arounds" to allow them to see it properly.
Is there any plan in the works by Microsoft to declare to no longer "support" the IE6 browser so that general folks who surf the web finally drop it and move up to a newer version?
Unless that is the case, the solution isn't quite THAT simple. Until IE6, the browser, has far less of the market than in currently does (less than 1-2%), you either have to target IE6 as the rendering mode in your documents -- or target IE8, with the addition of your hacks, conditional comments, and other odd workarounds to get the page to display properly in IE6, too.
Am I wrong about this issue? If so, please correct me.
It will just allow to have more than two mode (for the same engine). Also, the browser won't have to guess which one to use like they do now.
If you screw up some css3 or html5 implementation, you might need it.
@alex: It doesn't mean that you are targeting IE8, it just mean that it is compatible with IE up to IE8 (which mean that your site work for Safari3/FF3/Opera9.5/IE8 + fixes for IE7 and maybe IE6 if you still bother).
In contrast, bug fixes (and probably new layout features) in IE8 will only apply to IE8-mode. The other modes will simply never change. IE's modes are each defined as "whatever IE version X happened to do". There is not, and can never be, a spec for them.
Enough is enough Microsoft. Stop trying to change the rules and start following them. I don't want to loose the rest of my hair trying to debug IE8.....
"A lot of developers and their customers care about Firefox."
They care about being compatible with Firefox. Being compatible doesn't mean being standards compliance at all. People like us who care about standards are a vast minority. I'm talking about the majority.
Some developers care about standards, but how many care enough to practice it? Very few. This is why it's so hard to find a page that will pass W3C validation. Developers just care that their customer is happy.
Customers want compatibility. Customers don't care about standards compliance and most don't know anything about it. They just want their site to be viewable by as big an audience as possible, and they want it done as cheap as possible.
This falls back on the developers shoulders. Cheap means fast. Fast means WYSIWYG editors, like Frontpage and Dreamweaver. Those types of editors produce compatible code, but rarely compliant code.
I'm not advocating that we abandon standards. I'm all for standards. The majority of sites I develop will pass W3C validation, but no one cares but me. This is why I believe there needs to be a benefit to being standards compliant, or a penalty for not being.
There is an unfortunate cycle that isn't going to break anytime soon. Removing backwards compatibility would make most of the pages on the internet break. This would cause people to move away from the browser, and this is why it will not be removed. If it doesn't get removed, then there is no penalty for not being compliant, so why put in the effort? Without a direct incentive, this codependency will continue until browsers and tools are both compliant. We could be waiting a long time.
But because people care about staying compatible with Firefox, we make them build more standards-compliant sites by making Firefox more standards-compliant --- and by standardizing any Firefox-specific extensions that they like to use.
Why are we all trying to figure out how to make Microsoft's past mistakes seem more acceptable? Seriously, if anyone wrote a lot of code that only works in IE-6 then they deserve the full force of the pain they get when IE-not6 becomes the new fad. Do I feel an ounce of pity? Um....
If the page doesn't display properly for just one BAD BROWSER then let that browser's user get a browser than CAN display it properly.
"This page is 100% standards compliant, but YOU broke it by using a BAD browser! [with standards support from ten years ago]"
If the user is using a browser with 200 bugs that present it from displaying a page properly that looks fine in all other browsers then they obviously shouldn't be using that browser. Don't waste your time adding yet more cruft to your page to support the browser in question. Make a point of writing clean, efficient, valid code.
I realise that this is not generally possible on Commercial projects, but you certainly should code to this standard for personal projects. Now that all graphical http/html browsers support a good part of CSS level 1 and 2, javascript and DOM, most kinds of images (with appropriate gamma and alpha support), you have to reason to not use them. Your code will be displayed acceptably (often identically) in all these browsers, yes, often even on mobile with the advent of Opera Mini and such.
There is just one browser which will not display valid code properly, and you shouldn't soil your code to make allowances for this unacceptable software.
If your users have a problem with the way your stuff is displayed, they should upgrade to a proper browser (not just the cheap toy that comes as a part of a larger software package, to get you off the ground ;-))
Hey I love Microsoft, they make some excellent software, but their repertoire of excellent software certainly doesn't include a browser.
The standards exist, so do the validators and the compliant html editors. Code your sites to comply, it is up to the browser to render it correctly. The meta hack proposes just the opposite....the developers have to change the way they do things just so this browser will work. No argument will outweigh the fact that IE is still promoting non-compliant garbage code instead of forcing developers to comply. It's like peeing on the W3C.
A) its on an old Machine.
B) Businesses's don't allow updating IE6 to something newer
C) average user doesn't know how to update IE
I've never seen anyone say this but several companies created webbased tools or programs that only work on IE6. And until those companies fix those programs, Businesses are forced to stick with IE6. Even though sometimes were allowed to run FF3 side by side. We cannot allow all corporate users update IE because of support problems. This has nothing to do with the top 200 pages out there.