Wednesday, 23 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.



51 comments:

  1. The "Don’t Break the Web" argument they use is just silly, as every release up to now did it already, mostly due to new bugs...

    ReplyDelete
  2. It really makes this more complex for the web developer as well.
    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.

    ReplyDelete
  3. Wow, I hadn't even considered any of these implications. The whole idea's sounding worse by the hour...

    ReplyDelete
  4. Some *very* good points there.
    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.

    ReplyDelete
  5. Robert O'Callahan23 January 2008 21:08

    Robert: indeed.

    ReplyDelete
  6. It'll be funny when Internet Explorer 8 fails Acid 2, and Microsoft is trying to explain that it's WaSP's fault for not opting in enough to standards compliance.
    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.

    ReplyDelete
  7. Their "don't break the web" should be read "don't FIX the web".
    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 :)

    ReplyDelete
  8. It may be naive, but couldn't Microsoft just ship one DOM, which is extensible enough to turn off certain elements (if HTMLVers ? If they make their core flexible, they won't have any cross-version mess, and they'll be able to patch security holes while keeping additional footprint to a minimum.
    Of course, I think this whole mess is a TERRIBLE idea, but I think they could program around your holes.

    ReplyDelete
  9. Robert O'Callahan23 January 2008 22:04

    Eddie: that won't work, their DOM implementation has all kinds of insane bugs. They can't make big changes to it without risking breaking bug-compatibility.

    ReplyDelete
  10. virtualblackfox23 January 2008 22:15

    Funny feature, now what happens if "other browser vendors join Microsoft in implementing this functionality"...
    ---------------------------- 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".

    ReplyDelete
  11. virtualblackfox23 January 2008 22:27

    Just to clarify my "is tolerable by them only because they have a VERY big market share" sentence isn't exactly right.
    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.

    ReplyDelete
  12. Big surprise! Firefox not implementing some that IE does implement! Stop the presses!
    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.

    ReplyDelete
  13. Sebastian Redl24 January 2008 01:43

    Way to go, troll.

    ReplyDelete
  14. James, what exactly do you want Mozilla to be compatible with in this case?
    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.

    ReplyDelete
  15. Robert O'Callahan24 January 2008 02:01

    Nowhere in this post (or the followup post) have I argued that "Microsoft is evil".
    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.

    ReplyDelete
  16. I understand both sides of the story, both for and against this method. Unfortunately, this is a situation where you are arguing for the lesser evil. Neither solution is good.
    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.

    ReplyDelete
  17. Robert O'Callahan24 January 2008 03:01

    A lot of developers and their customers care about Firefox. As the standards get tighter and we fix our standards-compliance bugs, we'll see sites gradually become more standards-compliant whether they like it or not.

    ReplyDelete
  18. This entire blog post misses the point entirely. Backwards compatibility has always been a high priority for Microsoft; XP still runs software written for DOS 2 decades ago.
    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.

    ReplyDelete
  19. Robert O'Callahan24 January 2008 04:15

    I don't know for sure what IE does, but I know what Firefox does. Hacking multiple modes into the same engine, and continuing to evolve that engine, would be extremely complex and doesn't provide bug-for-bug compatibility guarantees, which is what Microsoft seems to be aiming for.
    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.

    ReplyDelete
  20. "So I want standards mode in Firefox, Opera, Safari, so I use the correct doctype. Now which IE engine do I want to use?"
    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.

    ReplyDelete
  21. From a web designer perspective, that whole meta tag thing seemed like a ridiculous idea to me, but from a browser developer angle, it seems to make even less sense... Great points there. Thanks...

    ReplyDelete
  22. My guess is that they're not adding more engines, but just bloat code with stuff like this:
    getWidth()
    {
    switch(bugmode)
    {
    case 5: return x;
    case 6: return y;
    case 7: return z;
    case 8: return width;
    }
    }

    ReplyDelete
  23. Robert O'Callahan24 January 2008 14:14

    kL: that doesn't really help much. you still have multiple engines, they're just woven together in the same source code. Arguably it's even worse. And the first time you try to redesign your code in major ways, you'll find that doesn't work anymore.

    ReplyDelete
  24. This is a great idea, and a perfect solution to all of our web development woes.
    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!

    ReplyDelete
  25. I really don't see the problem: IE8 will function like the crappy IE7 we're already coding for (and will be long after IE8 comes out), just don't add the stupid meta tag and you'll never even have to test on IE8 compatibility ;)

    ReplyDelete
  26. Fortunately, they include the option to say IE=edge and always get the latest available rendering. They don't recommend this, and they _shouldn't_ recommend it, because too many web developers who do what Microsoft recommends would use it and still code to IE's bugs and expect backward compatibility, kind of like what happened with DOCTYPE-switched standards mode. But for web developers who actually code to standards and then test in IE, who only work around IE's bugs in ways that don't break other browsers -- web developers like me, in other words -- the edge option is the only thing that makes any sense. Because when IE9 comes out, I don't want to have to dork around updating the meta tags in my pages in order to be able to take advantage of the things it gets right that IE8 got wrong. In other words, the edge option will hopefully be what the doctype was supposed to be (and would have been if people who code to IE's bugs hadn't started specifying doctypes).
    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.

    ReplyDelete
  27. Your reasons above are short, brutal, and definitive — it's a bad idea and the compatibility is an illusion.
    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.

    ReplyDelete
  28. Isn't this the same problem that Mozilla was having with XULRunner versioning. If I remember right (and I probably don't) the problem was that it would be easy to have multiple applications installed which all required a different version of the runtime. The solution (although it was never implemented) was to keep all versions of the runtime around, and launch different ones depending on the app's compatibility level.
    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.

    ReplyDelete
  29. As a web developer, my one-word summary of Microsoft's progress from IE6, to IE7, to IE8 as per this announcement: CLUSTERFUCK.
    Truly, the IE dev team should be the first ones against the wall when the revolution comes. Morans.

    ReplyDelete
  30. So your entire argument boils down to this: its a difficult problem and you don't think Microsoft (or Firefox) can pull it off? I think we can all agree that if it doesn't work as advertised it will not be beneficial. Is there any real criticism to this?
    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.

    ReplyDelete
  31. Robert O'Callahan24 January 2008 20:18

    adric, I guess you don't develop public-facing sites then, or you target one of the dwindling number of countries where non-IE share is low, or your clients are strangely myopic. But that's fine I guess.
    > 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.

    ReplyDelete
  32. I guess they added the "edge" variable (which means "pick the latest engine you have") for the people that wanted to just be forward compatible and expect browsers to meet the standards on their own time... without making compromises themselves.
    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".

    ReplyDelete
  33. This is a terrible idea. Horrible. Microsoft cock it up again. Takes me back to the browser sniffing days in the '90s! Oh the horror of it.
    By the way, your columns are too narrow. Having to keep jumping to the next line all the time makes reading too staggered.

    ReplyDelete
  34. This is how we are finally paying for MS's stupid idea of putting the browser in the OS. If they didn't do that then if your old unsupported intranet app requires IE6 then you can still have IE6 or any other version of IE you need on your system. But the rest of us can move on.
    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.

    ReplyDelete
  35. What worries me about this is what happens if other browsers *do* implement this feature. IE has had, what, 8-10 years to implement the standards, and they still haven't even managed that much. What makes anybody think that IE N is would render an "Opera 9.5" or "Firefox 2" page correctly, several years from now?
    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.

    ReplyDelete
  36. the purpose is to allow MS to implement non-standard features in IE, nothing else. then they can leverage that old reliable "embrace and extend" policy that has delivered so much control in the past. if they can get people to accept "" (which is standardards compliant), then add feature "wizzy" there will be all these fuckwits implementing "wizzy" from their MS desktop and we'll all be stuck playing catch-up again. it's so transparent it's pathetic.

    ReplyDelete
  37. attack surface is bigger in firefox than IE7/8, because firefox supports more standards.

    ReplyDelete
  38. Robert O'Callahan25 January 2008 23:41

    ficus: IE supports a whole lot of non-standard stuff that we don't, so their overall attack surface vs ours is hard to judge.
    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.

    ReplyDelete
  39. I dont get all the complaining.. This is a very small price to pay to Get IE 100% on board with a truly complaint browser on the next version!!
    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...

    ReplyDelete
  40. >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.
    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.

    ReplyDelete
  41. @roc: Would it be more complicated than having a quirk and standard mode like all browser have today?
    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).

    ReplyDelete
  42. Robert O'Callahan27 January 2008 22:45

    Yes. Our quirks mode is nothing like what IE is proposing. Basically we have "standards mode", and "quirks mode" is just "standards mode" plus a fixed set of well-defined quirk behaviours. That means that almost every bug fix --- and new feature --- applies to *both* standards mode and quirks mode. Our quirks mode is actually becoming gradually more standards-compliant over time (although obviously it can never be 100% standards compliant). This approach means that the extra Gecko code required to support quirks mode is quite small and is not increasing over time. It also means we could actually write a spec for our "quirks mode" is --- "the standards, except for the following exceptions: ..."
    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.

    ReplyDelete
  43. Full standards compliance is a pipedream, but full compatibility is one as well. Unless they're indeed shipping multiple engines, there could very well be bugs in future IE browsers that cause the different rendering modes to render differently across versions. That is, IE=8 rendering mode in IE 9 might contain some new quirk that IE=8 in IE 8 doesn't have. Wonderful.

    ReplyDelete
  44. This is rediculous. Sure there might be quirks in older sites, but it's time to cut and run. We're not talking about mission-critical stuff. It's time for Microsoft to admit to the world that IE6 was LONG overdue for update and that is the reason we now have this problem. Denounce the evils of your old crappy browser and move on to standards compliance - the last thing we need is another variable to control how our pages are rendered. Mozilla can get it right. Opera can get it right. Safari can get it right. KHTML can get it right. Time for Microsoft to finally join the club.
    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.....

    ReplyDelete
  45. I suspect this is MS hoping to leverage the tendency (as they see it: see the Halloween documents) for open source to "follow the tail-lights" of proprietary software. That is, they get Mozilla and/or Opera to imitate them in this foolhardy endeavor, thus killing the web-browser as a platform. It's clear they want to do that by the neglect of IE6 and the refusal to implement SVG, amongst other things.

    ReplyDelete
  46. Robert O'Callahan said...
    "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.

    ReplyDelete
  47. Robert O'Callahan1 February 2008 21:57

    You're right.
    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.

    ReplyDelete
  48. Horse, cart, people. Write code that is flexible by following the standards. If a web browser can't display that, then that's *their* fault, and you have an excellent reason to stop using it. Making it comfortable for people to leave their non-standard code all over the web is not a Good Thing. Making it comfortable for people to continue using IE-specific code is only good for Microsoft, so no wonder they're for it: duh!
    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....

    ReplyDelete
  49. Robert: DAMN RIGHT!!!!
    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.

    ReplyDelete
  50. I for one will be ignoring any "standards" that M$ tries to implement in IE. I would ignore any similar proposal by Mozilla, Apple or anyone else who suggested such rubbish.
    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.

    ReplyDelete
  51. The main reason we still see people running IE6 is:
    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.

    ReplyDelete

Note: only a member of this blog may post a comment.