Wanna know how I can tell that no other browser vendor participated in the creation of the new meta X-UA-Compatible tag? Because it’s completely worthless – and in fact harmful – for any browser to implement!
I love this example from the overview article, including Firefox 3 as an example:
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />
What seems to have slipped past the Microsoft Task Force of WaSP (or maybe it didn’t and they’re just playing coy) is that by implementing this specific feature in any other browser immediately either: A) Reduces its market size of viable web pages that will upgrade to new versions of the browser or B) Forces new versions of the browser to bloat, including backwards support for old-style rendering.
The fundamental issue is that Safari, Firefox, and Opera will all be harmed by attempting to implement this. Anne, from Opera, completely agrees. So, with that in mind, why even the attempt at making this sound like a “generally beneficial standardization issue”? Why go through the song-and-dance? Because if it was called:
<meta http-equiv="X-IE-VERSION-FREEZE" content="IE=8" />
then developers would surely, excuse me, shit the bed in frustration over being forced to add markup just to make their web applications render in a standards compliant manner. The comments on the article definitely indicate some level of this occurring already. However, the pretense of cooperation and generally applicability needs to be dropped. It doesn’t exist, it’s a complete lie, and any indication of general use is a sham. Call it for what it is: A shiv for jamming standards support into future versions of Internet Explorer.
JavaScript and X-UA-Compatible
With that rant out of the way, how will this new meta tag addition effect JavaScript and DOM support in future versions of Internet Explorer? That’s the weird part – no one completely knows. Let’s look at some randomly-picked issues that are sure to cause a world of fun in the future.
Cross-document issues
Let’s say you have a page that’s in IE7 mode and an iframe pointing to a page that’s in IE8 mode (or vice versa) – and now you communicate across the frames. Now let’s assume, for fun, that IE8 also support JavaScript getters and setters.
var iframe = document.getElementsByTagName("iframe")[0];
iframe.contentWindow.someObj = { get value(){ return true; } };
iframe.contentWindow.someObj.value // ??
What happens when you bleed functionality across frames? Or even if you were to try and access functionality that doesn’t exist in your engine from another? Who knows! This is positively frightening both from an implementation and user perspective.
Another random item: What happens when you use importNode across iframes that have different DOM versions?
Robert O’Callahan, Mozilla developer, has two blog posts on the subject that are both quite good.
Script Versioning
Up until this point, if we wanted to pick a different version of JavaScript to use we would do something like the following:
<script type="application/javascript;version=1.8">...</script>
This works well in browsers that support it. However, with this new meta tag addition, Internet Explorer is pegging JavaScript versions to versions of their rendering engine. This means that (theoretically) if you wanted JavaScript 1.5 support you’d have to, also, be content with bad CSS support. If you wanted to upgrade to a new version of the scripting engine you’d also have to upgrade your CSS and markup as well. This is completely throwing out any sort of versioning system that already exists for JavaScript and forces users to use this new, inferior, system instead. How completely frustrating.
What I also find interesting is that, previously, Chris Wilson was concerned about implementing multiple versions of a JavaScript engine in order to maintain backwards compatibility. What they’re doing now is, effectively, forcing themselves to have multiple JavaScript engines. So either they’re gearing up to support JavaScript 2 or they’ve just lost one of their major qualms with the upcoming specification.
Minor Versions and Security Fixes
A final point that doesn’t seem to be accounted for, at all, is the inclusion (or exclusion) of minor browser versions (including things like security patches). Internet Explorer hot patches have been known to cause problems in the past with web page functionality and rendering. However, since there’s no way to specify which patches you “like” in this new meta tag scheme you’re forced to consume them all.
The end result will be one in which: A) You’re either constantly dodging mistaken bullets from the Internet Explorer team as the push out new releases or B) They’re not going to do as many, if any at all, updates to the browser out of fear of breaking backwards compatibility. Honestly, I assume that B is far more likely, therefore you can be excited about looking forward to future, static, bug-laden releases of IE in the years to come!
On a whole, I really wish that this process had been done more in the open than it was. I doubt that as many issues, that we’re seeing now, would’ve arrived. I absolutely don’t envy Internet Explorer’s situation in the matter so, for the sake of the web, let’s hope they come up with an acceptable solution.
Dossy Shiobara (January 22, 2008 at 3:49 pm)
Is it time to declare browser compatibility bankruptcy and just start over?
Andrew Dupont (January 22, 2008 at 3:56 pm)
Your JavaScript example is a mindfuck, but so would it be even if IE had adopted the mime-type approach to JavaScript versioning.
I agree that the process should’ve been more open; I agree that this is a strange and ultimately ill-advised path for Microsoft to go down. But I don’t think the outcome would’ve been any different, nor would IE be better-equipped to get out of the corner it’s painted itself into.
Steve (January 22, 2008 at 4:05 pm)
That was about my thoughts on the subject.
Here’s a response from Mozilla: http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
Jonathan Snook (January 22, 2008 at 4:22 pm)
The cross-frame JavaScript issue won’t be very common. If you can’t control the content from all frames then you’re likely dealing with cross-domain issues. In a cross-domain environment, then wouldn’t any getter/setter in an alternate frame cause issues like that? Even if all frames were using the same DOM engine, it seems to me that you’d still have this problem.
Ted Henry (January 22, 2008 at 4:23 pm)
The people that come up with this stuff should loose their jobs. Microsoft needs some balls. Just rip off the bandaid. Sure there will be some pages that break but if IE becomes standards compliant they won’t ever have to go through anything this bad again. They are a bunch of babies.
Robert Accettura (January 22, 2008 at 4:27 pm)
There’s a big difference between doctypes, js versioning and this.
One specifies what set of standards to obey, one says what browser the code is crafted towards.
It’s easy for a developer to stick to a defined spec. It’s virtually impossible to hit a moving target like this when multiple browsers are involved.
I’m a fan of using doctypes and JS versions to be honest. They are great ways of telling the browser your intent.
But to pick a rendering engine? That’s just asking for trouble.
Not to mention most developers will just stick with the oldest and most lax engine, further hindering web standards from growing.
Jonathan Snook (January 22, 2008 at 4:46 pm)
@Robert: the fact is, using a doctype switch is picking a rendering engine. It’s the original incantation of the versioning switch that people are talking about today.
I also don’t see how being able to stick to the oldest and most lax engine will hinder web standards any more than the doctype switch has.
Here’s my opinion in the most pragmatic approach: I do things that are easy. Having access to advanced CSS selectors, generated content, etc, etc, make my life easier.
Should we force all pages to render using the most up to date rendering engine, breaking web pages at the expense of end users, just so that web developers can understand that there’s a ‘better way’? That just seems selfish.
Mike Purvis (January 22, 2008 at 5:32 pm)
Glad to hear your perspective on this. I was shocked to see Eric Meyer on board with it, but you’ve definitely brought forward some objections that go well beyond philosophical opposition—clear and concrete examples of trouble ahead.
Based on the ALA article, it seems like a big part of this is supporting old sites, and allowing us to surf “the historical internet.” That seems like a totally misguided goal. Now browsers should serve users of the now internet, and sites should be prepared to upgrade and adapt. If a library is keeping archives of old pages, they can also keep old browsers around to view them with.
Tiest Vilee (January 22, 2008 at 6:08 pm)
So, if I ask for an older renderer/js does that mean I get all the vulnerabilities that have been patched in the newer versions? So I, as a malicious script writer, can target my attacks at exactly the version of IE I know contains the hole?
Sounds great to me.
DavidONE (January 22, 2008 at 6:49 pm)
Pleased to see another ‘voice of authority’ coming out against this ludicrous proposal.
What we’ve been handed is a proposal, reached behind closed doors, driven by MS (a company who has consistently promised and not delivered on standards adherence) for the benefit of MS, and all of it legitimised by a handful of supposedly independent experts who *really* should know a lot better.
For those who haven’t seen it, Zeldman has weighed in – http://www.zeldman.com/2008/01/22/in-defense-of-version-targeting/. Part of his defence of the proposal is that MS devs will get sacked if it’s not implemented. I’m not joking.
Andrew Dupont (January 22, 2008 at 7:08 pm)
(emphasis mine)
DavidONE, let’s please just calm down for a second. Smart people can disagree on this one, so let’s not start questioning the integrity of ZELDMAN, of all people, by suggesting that he’s been bought off by MS.
You’re free to attack his arguments, but attacking his character won’t earn you points with anyone.
gonchuki (January 22, 2008 at 7:14 pm)
I’m with you on this one John, it’s complete madness to even having thought all the bloat that comes with this “idea” would be good for us.
And still my greatest concern on this is the freezing spell casted upon our sites… seems that progressive enhancement will be long gone unless you come months or even years later to tediously and manually update your “outdated” meta-tags.
I don’t even get why would this be necessary, given that if they fix their rendering errors for IE8 that should put them on par with the rendering obtained from FF/Safari/Opera, that as far as I remember do not require any kind of weird meta hack.
Guy Fraser (January 22, 2008 at 7:18 pm)
There’s a finite number of existing web pages on the interweb, only a fraction of which will break on a standards-compliant browser.
There’s an infinite number of future web pages, most of which will require a standards compliant browser.
Why is the hack tag being applied to the latter and not the former? Why not run in standards mode by default and have the hack tag added to the vast minority of sites that would break in standards-compliant browsers?
Ponders that question all day… Answer: IE lock in!
Chris Wilson (January 22, 2008 at 7:18 pm)
John Resig – perhaps I’m too close to this then. I want to jam standards support into (this and future versions of) Internet Explorer. If a shiv is the only pragmatic tool I can use to do so, shouldn’t I be using it?
I’ll detail more about the Javascript solution in the future – the short answer is that it’s not two engines, it’s two modes of a single engine; we can, in fact, work across boundaries like that.
I won’t get into the JS2 discussion here.
@Mike Purvis: the “now internet” as you put it wasn’t developed with IE8’s standards behavior in mind.
@Tiest Vilee: it turns out the IE team is not, as seems to be generally assumed, complete morons.
@DavidONE: no, Jeffrey Zeldman’s point was that if Microsoft was inundated with complaints (and support demands, etc) for IE breaking web sites, those of us on IE who care about and advocate for standards support would take the blame and depart, not just random MS devs.
John Resig (January 22, 2008 at 7:35 pm)
@Chris: Thanks for responding. My two biggest concerns are:
1) Having this be portrayed as a general-purpose solution for all browsers, when it’s really just a solution to Internet Explorer’s situation. That’s not necessarily a bad thing. I completely commiserate with your situation and don’t envy it at all. It may very well be that this new meta tag addition is the only viable solution – and that’s fine. However showing it as something that is a universal issue to all browsers is definitely not the case.
2) From a developer perspective, I’m definitely interested in hearing more about the JavaScript implementation and the issues surrounding it. It is interesting to learn that it’s a single engine split across boundaries and does derail the comments about JS2, feel free to ignore them. Definitely can’t wait to hear more.
Rosyna (January 22, 2008 at 7:45 pm)
“the “now internet” as you put it wasn’t developed with IE8’s standards behavior in mind.”
Uhm, some of the “now internet” was developed with standard behaviour in mind. Which means IE8 still won’t render these parts of the “now internet” correctly if IE7 didn’t do it correctly.
Moran Ben-David (January 22, 2008 at 7:46 pm)
This makes perfect sense to me… Microsoft’s decision to “jam” web applications fits with their need to dislodge the tsunami that’s hitting their products. Standard browsers commoditize their products (windows os + ms office)… they can’t have that… so they’re trying to make the browser harder and harder to code for.
It’s a sad state of affairs.
Bryson (January 22, 2008 at 7:51 pm)
The problem I have is that this issue stems from too many people who accidently used the DOCTYPE when they shouldn’t have (for whatever reason).
To me, that just looks like another honey pot for dumb developers.
I just foresee the same thing happening again with this Meta tag as new bugs get introduced with the normal course of development of IE in years to come. What then??
Bryson (January 22, 2008 at 7:52 pm)
Sorry, the politically correct phrase is apparently, “inept developers.”
gonchuki (January 22, 2008 at 7:52 pm)
@Chris:
IE8 standards behavior *should* be the same standards behavior that FF/Safari/Opera embrace today using different engines, yet they work together flawlessly without needing hacks on almost every site you come by (with differences coming down to the pixel level, in almost all cases not affecting the end-user experience.)
Shouldn’t be your job to follow the same path instead of creating a parallel path of vendor lock-ins to compensate your inability to accurately render a web page?
catenoid (January 22, 2008 at 7:57 pm)
Is there a reason why Microsoft couldn’t ask W3C to bump the version numbers of everything by .01 and then render in standards-compliant mode for DOCTYPEs with these new versions, with deviations filed as bugs? There’s no way MS wouldn’t have enough pull for this.
I can see why MS wants to leave a get-out-of-jail-free card in the spec for future standard-slippage, but I don’t see why it’s in our interest to let it happen.
I do wonder if W3C’s been overly optimistic regarding the implementability of its Recommendations – the lag between Recommendations and widespread support has been huge in a number of cases. Emphasis on having running implementations prior to issuing a Recomendation may help there.
pd (January 22, 2008 at 9:26 pm)
I don’t get it. Is everyone flying off the handle for no good reason?
If 90% of web pages are turning on IE8 ACID2 mode when Microsoft start IE9, surely they will drop this three-level compatibility crap?
I think this is all a massive legacy of the lack of true competition until Firefox came back to bite MS. IE was allowed to become THE world wide web and hence heaps of people have coded sites (particularly intranet ware) according to IE6’s proprietary buggy modus operandi.
MS is now effectively saying we want to get to a standards compatible browser without sacrificing those who have built decrepit sites based on IE6.
We should be focusing on forcing major vendors like Oracle/BEA to upgrade their code beyond their current IE6 compatibility, not hassling the IE team for trying to make progress with the burden of a monopoly legacy.
By the same token Chris Wilson should pull his head in and ackowledge that his status of running the biggest browser in the world, is completely derived from monopolistic anti-competitive practices and therefore is not ‘real-world’ any longer.
Seamus (January 22, 2008 at 10:57 pm)
“FF=3”? At the very least they could have used “Gecko=1.9” which is the actually name and version of the rendering engine for Firefox, Camino, Sea Monkey, etc.
Daniel Pihlström (January 23, 2008 at 2:49 am)
Now I agree that the X-UA-Compatible thing isn’t exactly a pretty solution, but on the other hand I don’t have the issue of having to supply a browser that will both work according to standards, without neccessarily breaking all the web sites that functioned in previous versions.
I would in part prefer that they took some effort into pushing out an easy way to use IE8 in a beta mode for some long period of time prior to release (something like the IE7, just with side-to-side with the older versions.. Here we had to keep virtual machines with IE7 to keep up testing, these are gradually being replaced by IE6 VM’s.).
On the other hand, if they broke several hundreds of our older sites and we had to go through the work of correcting all of them.. That would take a whole lot of time that we just don’t have to spend on a browser upgrade.
It seems to me that it’s going to be neccessary for them to keep having to consider their past mistakes until sites pick up the slack and improve their code.. On the other hand, if the code keeps working, we’re not going to fix them. :\ It’s harsh.
Still, it’s an http-equiv meta tag, so you could always slap in a “X-UA-Compatible: IE8” in your custom headers if you want to keep your code clean. (Ofc that’s a 22 byte added overhead on every http request)
Anup Shah (January 23, 2008 at 6:56 am)
John, I think your final paragraph is really important, (about wishing the whole thing was done in a more open way, and not envying the mess IE is in).
I’d be interested to hear what other opinions of solutions would be? Personally I would think conditional comments for IE, progressive enhancement seemed to be a good principle to deal with all this. Am I missing something (other than what seemed to be IE/ALA pointing to developers using standards compliant mode)?
DavidONE (January 23, 2008 at 11:15 am)
Andrew Dupont: “… let’s not start questioning the integrity of ZELDMAN, of all people, by suggesting that he’s been bought off by MS”
I wasn’t suggesting anything as dramatic as that. I’m questioning the judgement of Zeldman and the other independent operators in this ‘project’ – Stockholm Syndrome was mentioned elsewhere and might explain how this has happened. A decision reached behind closed doors (at Microsoft) is handed down which benefits only Microsoft and harms web standards and browser competition. It’s endorsed by some people who were on the side of web standards above all else (To Hell With Bad Browsers, etc.), and now they’re advocating for one browser from one company with a long history of ‘divide, assimilate and conquer’ – hence “supposedly independent”.
Chris Wilson: “… those of us on IE who care about and advocate for standards support would take the blame and depart, not just random MS devs”
I didn’t suggest random MS devs would be fired. I don’t believe any devs would be fired. I don’t believe a person would fire loyal, dedicated employees for making better software. However, if that did happen, it still doesn’t make this proposal correct or desirable for the future of web development.
Lars Gunther (January 23, 2008 at 2:56 pm)
If Chris Wilson et al are in such a weak position at MS that they might get fired for doing the right thing, why on earth should we care? Sorry, Chris, I see you as a really good guy and I do wish you all the best. However, you will not be in any trouble finding a new job for a better employer.
The argument is nothing but FUD and besides the point!
MS as whole do not care very much about standards, as is evident from the mega-stupid decision to use “the Word rendering engine” in Outlook and push Silverlight at all costs. That a small group within MS do care is MS only hope to keep some foothold on the browser market. If CW et al are gone and MSIE gets further away from standards it will only mean one thing: In a few years MSIE will be dead – totally dead.
That will not be the end of life for standards aware devs at MS, as they will get new good jobs. It will for sure not be the end of the web – au contraire! It would only be MS shooting themselves in their foot. Which they are free to do if they want.
Nathan de Vries (January 23, 2008 at 7:03 pm)
You’ve brought up a number of issues which immediately sprung to mind when I first looked at this proposal too. Namely:
1. Standards are a fixed target, browsers are a moving target. Shouldn’t we be implementing against the fixed target and accounting for the moving target’s discrepancies with the view that they’ll be fixed over time?
2. Browsers have minor versions where the above mentioned discrepancies are fixed. Do we pin to minor versions too?
3. Is it possible to declare that everything on a single page (Javascript, HTML in frames etc.) are pin-able to the declared UA?
From Chris’ comments, it seems like ScreamingMonkey will not be required if a multi-mode JS 1/2 engine is in the works. I look forward to hearing exactly how this fits in with the X-UA-Compatible switch.
Santos L. Halper (January 24, 2008 at 4:19 am)
That would be as true as: You got an email address, you asked to be spammed.
Considering that the preferred abbreviation is “Fx” or “fx”, this is even more inane.
John Foliot (January 24, 2008 at 3:20 pm)
…an interesting aside that probably slipped by most.
Last week while lamenting the fact that Google lacks a DTD, I was asked about whether or not I had thought through page size. I hadn’t. While 22 bytes seems trivial to the point of absurdity, when you multiply that by the sheer volume or traffic that sites such as Google deal with… Hmmm, that does become a bandwidth issue.
Wondering if anyone else thought about that as they (we?) add yet one more line of code to each and every page shipped out…
Once upon a time, Netscape *WAS* the web… come’ on, you all remember that don’t you? But browsers come (and apparently go), and life continues to go on. Perhaps what MS needs to do is stop making “Internet Explorer”, and start out again fresh with “Web Wanderer” (note to marketing dept. – come up with a catchier name). This new browser could be Standards compliant to the Nth, and could happily co-exist with it’s older, less compliant sibling. Let the end user have a choice, even if it is between 2 competing MS products.
Or am I just wishing too loudly?
David Christian Liedle (January 25, 2008 at 4:45 am)
@John Foliot: I love the idea of a new M$ browser! I’ll wish loudly with you, and together our voices may be heard. ;]
@anyone who cares:
I’m surprised nobody has drawn from other analogous dilemmas that have been successfully solved, or at least widely accepted as normal, in areas besides web browsers:
1) Apple
The switch from OS9 to OSX was huge. Adding carbon to OS9 and implementing it in OSX formed a sort of glue that allowed developers to survive an amazing leap. Again, moving from the PPC chip to Intel was huge! But not so painful. Rosetta allowed legacy code to think it was running business-as-usual. To apply that to IE8: what if they were to virtualize the legacy renders, with the option to turn that OFF? Just like kicking into quirks mode, certain obvious patterns in IE6-or-7 specific code could crank up the virtual machine to perform its geriatrics.
2) Flash
Anytime a user comes to a page with Flash content in a version newer than their Flash player can handle, they have to download the latest plugin to see new content. That’s not a solution, that’s a problem (or so many users would view it). The point is that its a workflow that has been accepted: go about your business unless the page doesn’t display right; then go get the plugin that makes it work!
Of course, that example relates to getting new technology, not hanging onto the old ways. But it works backwards, too:
That got me thinking about handling rendering engines sort of like plugins. To apply that to IE8, what if they were to make these numerous old-version-compatibility rendering engines available as a sort of plug-in for IE8? If you need MSIE 5.5 results, download the MSIE 5.5 rendering compatibility module. You’d know you need it when you come across a page that is “broken”, when the tech support guys install it for you, or when IE8 resurrects Clippy to announce, “I see you’re trying to view an old web page. Would you like me to install an active-x control to make this possible?”
</2cents>Gilbar (January 30, 2008 at 1:03 am)
Seriously, the one option I hope most follow is to block IE8 traffic to popular sites and promote the true standards compliant browsers. Surely the IE team would be forced to, as previously stated, rip the bandaid and do let the legacy clients go. It may be the developers, and thus the users, that push this through.
akatsuki (January 30, 2008 at 2:45 pm)
I am more inclined to browser sniff and then forward IE8 users to the Firefox home page than comply with this ridiculous tag. I could have handled bumping the XHTML version by 0.1 but forget about this proprietary nonsense.
David Christian Liedle (January 30, 2008 at 7:11 pm)
Somebody’s got to “rip the baind–aid.” Asking users to switch browsers means they feel the pain (of change) directly, but if Microsoft won’t turn out a browser capable of handling standards, users will suffer in the long run too…
I’ve considered creating a dismissible css layer “nag–screen” that allows viewers to use IE to access content, but reminds them that they aren’t using a real browser. Beats losing traffic to the Firefox page (although I admit, that is a noble cause to lose traffic for). Remember, some users are stuck on a corporate or school policy locking them in to IE, and cannot make the choice to change browsers.
Users might not understand or get riled up about “standards compliance.” But it doesn’t take a tech–savvy user to come up with a powerful activist stance regarding “that annoying error message on every site” needing to be dealt with. The only way to appease users would be to switch to a compliant browser. That sounds so manipulative, but it is one way to push back if MS keeps stomping on both users and developers…
</3rdCent>Vincent J. Murphy (January 30, 2008 at 9:54 pm)
The versioning (depending on it’s final form) would also need to include platform (unless there’s an assumption that, for example, IE5 is the same on both Mac and PC). It would quickly get out of hand.
Robby (February 1, 2008 at 3:53 am)
The thing that frustrates me the most is that IE is used not only as a browser, but as a developers toolkit.
The debates on embedding IE into windows has gone far and wide, but why can’t they just tweak IE as it is and be done with it, treat it as legacy (just like a DOS program for instance) and then develop a whole new browser, one with it’s own user agent string so web developers can develop and test against it, just as they done again Safari (the last “new browser” to come to market).
Best of both worlds I would think. One they would have the legacy toolchain for intranet, development tooling and even web development in general without the headaches of breaking what IE has done.
And then they can implement standards as they should be in a browser that we can treat as new, rather than code around the hazardous trap IE has become.
Sigh..
Gaurav (February 1, 2008 at 10:25 am)
Has it occurred to anyone, especially those that are advocating putting “edge” on their pages right now, that maybe it isn’t just inept developers and old sites that are not X-UA-Compatible? What if IE8 only partially implements the DOM event model, supporting “addEventListener” but not “stopPropagation”, for example? What if “getElementById” is fixed but the anchor tag stays buggy? Standards compliant pages could be broken by IE8. What if it isn’t a minority of pages that would be broken if IE8 was the rendering mode by default, but the vast majority, both standards compliant pages and dumb IE6 pages made to work around Firefox and IE7 changes? The only things Chris Wilson promised us was that IE8 mode would be more standards compliant, pass ACID2, but not fully 100% compliant. He in fact said that we would probably be disappointed. The particular silence around DOM issues is what worries me the most.
Nathan (February 21, 2008 at 3:53 am)
@ Jonathan Snook: “Should we force all pages to render using the most up to date rendering engine, breaking web pages at the expense of end users, just so that web developers can understand that there’s a ‘better way’? That just seems selfish.”
Yes we should, but the idea that every web developer must bend over to appease Microsoft to help them save their market share… That is selfish on Microsoft’s behalf, and do not try to say it’s not… Besides the fact it goes against everything the standards movement stands for.
This is the most absurd proposal we should ever have to see in our life time, this is all about one thing and one thing only, Microsoft’s market share, there is no argument in the world that can dismiss that fact so when I see highly respected members of the standards movement supporting this proposal it sickens me (for lack of a better description of how I feel).
I’m with those that have said they will happily drop support for IE, because I for one will not spend the rest of my career supporting a corporation that does not support “us”.
I’m so saddened to see such a small minority of web standards advocates give up so easily to the whims of a corporation that has stifled the advancement of the web for so long, the fact that they have rushed to the defence of Microsoft and turned their back on their peers is testament only to Microsoft’s marketing power… How dare you sell out so easily.
My 2 cents for now but I have a few hundred dollars I’m will to spend in this debate.
BTW John, good to see someone raising some of the issues that were obviously over looked when MS made this decision.
Image Hosting (May 5, 2008 at 2:33 pm)
This is retarded. If you’ve learned anything in developing IE, it’s that new versions don’t encourage developers to use standards. They’ll open their site in IE, and see that their IE5 code looks the same now. If it looks the same, then why change coding techniques? I thought IE8 was about advancing the web. I thought advancing the web didn’t include stuffing your head with useless meta tags.
RiTarDid (May 10, 2008 at 5:12 pm)
Standards exist for a reason. I didn’t feel sorry for developers who produced garbage code that worked in IE6…they created their own hardships by not complying with standards, and they paid for it when IE7 broke their sites. Development of IE, Firefox, or any other browser should not have one iota of consideration when developing sites. Develop your sites with compliance in mind; it’s up to the browsers to render them in a compliant fashion. If your site is compliant and IE is the only browser that won’t render it…to hell with IE. I will be ignoring the meta hack in my sites; regardless of what Micro$oft thinks I should do or not do; and I would recommend the IE team to drop all these stupid browser targets and just produce their first ever fully compliant browser instead of peeing on the W3C.