Compatibility, or “Just Don’t Break My Site!”
The information published in this post is now out-of-date and one or more links are invalid.
—IEBlog Editor, 20 August 2012
We’ve had more than a few comments suggesting that IE works too hard at backwards compatibility, and we cater to those people who “don’t code their pages correctly”, or people who otherwise “didn’t do things the right way”. These comments frequently go on to suggest that we (the IE team) should use our market position to “force people to fix their broken stuff”.
I’d like to explain why we so adamantly disagree with that position, and why we work so hard at backwards compatibility.
We feel it is vitally important for web sites and applications that worked with yesterday’s IE work with today’s IE, and continue to work with tomorrow’s IE. We feel this is a deeply held expectation by the millions of IE users.
In XPSP2, we sometimes had quite a struggle balancing the need to increase the security of the browsing experience and platform with living up to our compatibility responsibility.
Part of this struggle was because we have an incredible number of different users and developers using IE in many different ways, and we have to take all of those customers into consideration when developing and testing changes to our code base, especially security changes. Any change we make, be it a hot fix request from one particular customer, a security fix based on investigation external or internal, a fix to an issue reported through Windows Error Reporting, or a simple bug fix, could have potentially far ranging consequences throughout our user base.
Does all this mean we can’t (or shouldn’t) make changes? No, not at all. We can and will continue evolve IE towards better functionality, security, and stability. But it does mean that we need to move carefully with deep consideration of the impact of our changes.
We may take steps to mitigate compatibility issues with changes we want to make. For example, in Internet Explorer 6 we introduced the strict doctype to allow us to improve our CSS implementation without impacting existing HTML pages. We expect to use similar techniques for future enhancements where we might affect existing content.
One of the most difficult tradeoffs is when a change pits one set of customers against another set. Make the change, and N millions of customers are happy and K millions of customers are unhappy. Don’t make the change, and the N and the K reverse. As we were making changes for IE for XP SP2, when we found ourselves back against the wall like that, we chose security over compatibility. And if you read the industry press, you can guess how many N millions of customers are happy with our choices and how many K millions of customers are unhappy about it.
With Windows XP SP2 we had an open beta program so that we could make changes to improve compatibility based on customer feedback, and we reached out to developers to help them get compatible when security considerations warranted causing some level of incompatibility. In the end, we believe that with XP SP2 we have the balance about right.
Thanks
Dave Massy
Comments
Anonymous
January 01, 2003
Hi Dave,
This is great to hear! It is constantly what I'm telling people. Missing tags, mismatched tags, the forgotten semicolon in javascript. Are these really reasons to dismiss an entire web page? No. Should companies and professionals create well formed HTML? Of course. But there are so many hobbists not to mention the millions of families and friends that create web pages to inform loved ones. Why should their little spot on the web be trashed because browser developers are too lazy to put in the extra effort. Anyone can write a parser that checks tags and whatnot dismissing any page with an error. It is the browser that can handle these small mistakes and still render something readable that is truly useful.
Then you have the small businesses that use WYSIWIG programs to create their pages. Valid tags are going to get deprecated, so all of their websites should be rendered useless in the next browser update.... That's rediculous. Keep doing what you're doing. IE has it right and that is shown by the huge market share it still commands despite the competition and doomsayer media doing their best to oust it. Ken.Anonymous
January 01, 2003
> Missing tags, mismatched tags, the forgotten semicolon in javascript. Are these really reasons to dismiss an entire web page? No.
I sort of have to disagree with you there. Consider especially the case of a missing closing-comment tag.
By allowing sloppy code to go through, you're not allowing developers to get an accurate world-view of their pages during the development process.
I'd like to see a browser that can be switched into "strict interprative mode" for developers, but defaults to "loose interprative mode" for browsing. Of necessity, any site that works in strict mode should still work in loose mode.
This will allow developers to catch the missing semicolons, tags, etc., while still grandfathering in all the existing bad code out there that worked in the loose rendering model of previous versions of IE.
WYSIWYG (I think you have a Freudian slip there... what you see is what I get?)
On the other hand, if you're just adding functionality I don't see how sites could break.Anonymous
January 01, 2003
Is it telling that there is only one comment on this page? I think that's an inidication that the two people who have written on this page are completely oblivious to the world of "web standards". There are millions of web designers and developers that are just waiting for Microsoft to finally give up on its goal of trying to standardize the web for themselves and not follow the recommendations that the W3 has layed out and that ALL OTHER BROWSERS are adhering to.
The world would be a much nicer place to live in if IE finally got around to doing the same!Anonymous
January 01, 2003
I dont see how fixing bugs like these:
http://www.positioniseverything.net/explorer.html
and adding more CSS support would break existing applications. This just sounds like a bad excuse of being the browser with the worst standars support. You did improve the CSS and DOM support from version 5 to 6, why just not continue doing it?Anonymous
January 01, 2003
I also want the C++ compiler to understand that when I write if( i = 0 ) then I actually meant i == 0 instead of just breaking my code. There's tons of hobbyists who do not understand C++ well, so Microsoft, stop breaking our code :)Anonymous
January 01, 2003
Maurits - thats exactly what the strict doctype is kinda doing, although once you leave it switched on...Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I wish people didn't feel the need to promote other browsers and bash stuff here. Compare all you want, but unrelated bugs and "Firefox is great" just don't do any good. You can get that stuff anywhere but where else will you find information straight from the IE team?
The thing I wonder about with IE's compatibility is, what do you do with rendering bugs in strict mode? Do you break pages that rely on those bugs, or do you end up with multiple strict modes?
Non-strict parsing was a bad idea. Now you have all that old broken markup, much of which no one will ever touch again. IMO the best approach would be to continue allowing it, but put one of those warning bars across the top of the page to discourage new broken markup.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I wrote something about this: http://annevankesteren.nl/archives/2004/06/standard-compliant-ie
Using the XHTML MIME-type to trigger full standard compliant mode IE could continue not breaking the web, while supporting standards for those we need it.Anonymous
January 01, 2003
lowercase josh! That's exactly what i was thinking! Like in FireFox when it blocks a popup, IE could have the same kind of bar, but for particular html discrepancies! nice... are you listening IE team? :)Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
> I'd like to see a browser that can be switched into "strict interprative mode" for developers, but defaults to "loose interprative mode" for browsing. Of necessity, any site that works in strict mode should still work in loose mode.
I would fully agree. As a developer, it would be extremely useful to be able to switch one's browser into a (strictly) development mode where ONLY valid pages display.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Internet Explorer should stop compensating for the bad code of the past, and work in the official code of today, and more importantly.
I use Firefox, and it is VERY RARE that a web page doesn't display perfectly.
In Internet Explorer (which I stopped using for security reasons) valid pages should be displayed correctly, and if the user sees a page broken they can force IE to use the old engine.
Regards,
Stephen O'Brien
StopIE.comAnonymous
January 01, 2003
> forgotten semicolon in javascript
Javascript doesn't require semicolons. The parser is required to add an "implicit semicolon" wherever necessaryAnonymous
January 01, 2003
> Every browser apart from IE supports
> this API for plugins (Opera, Firefox,
> Mozilla, Netscape, various Linux
> browsers), and IE used to support it
> back in the days it was playing
> catchup. But in 5.5 you removed it I
> guess in an attempt to make people
> just write IE only (ActiveX) plugins.
Internet Explorer's support for Netscape plugins comes from an ActiveX plugin, plugin.ocx, that loaded the appropriate Netscape plugin for the MIME type. I have IE 6 SP 1 and plugin.ocx is still there. Of course, the reverse is impossible, since the COM-based interface of ActiveX plugins is so much better than the obsolescent and ad-hoc interface of the Netscape plugin API. So you're wrong on both accounts
> A decision which is to blame for some
> of your biggest security holes.
No. Netscape plugins not only are loaded through an ActiveX control, but nothing in their API protects them. They are still scriptable, run as native code and are initialized with untrusted input. ActiveX is a powerful and solid technology, there's nothing intrinsically broken about it
The real issues are IE allowing scripts to instantiate any ActiveX control, and lots of UI issues (warning the user when failing the operation period would have been better, and other such things). And badly written controls, but the IE team can't do a lot about itAnonymous
January 01, 2003
This whole web standard stuff isn't about backward compatibility. We - developers - have to work twice more because we have to make a standard compliant webpage and an ie_bugfixed version. All the old and not-so-well-made pages will have their problems if IE would use W3 standards? Perhaps. But decide which is the best: having some buggy old hobby-pages or have these bugs conserved forever.
I would chose to respect web standards and if the IE team is only thinking of 'backward compatibility', pray for the success of Firefox. (or any other real browser)Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The real problems are not caused by attempting to maintain backwards compatibility. The real problems are caused by not bothering to conform to spec.
For instance, missing units for non-zero lengths in CSS. The specification clearly states that the rule should be ignored. Internet Explorer treats them as pixels.
This means that when somebody is checking their work in just Internet Explorer (the vast majority of the 'hobbyists' Ken refers to when defending Microsoft), they aren't going to be aware of their mistake. It means that they are going to be destroying the layout for anybody not using Internet Explorer. It does web authors and non-Internet Explorer users a disservice. But as long as the web authors don't realise this, and the non-Internet Explorer users don't realise what causes it, I guess Microsoft can get away with it, right?
If Microsoft were to fix this issue, the only people who would notice are the ones whose sites were already broken in other browsers. And it might break temporarily, but it would be quickly fixed, and it would raise the reliability of the website, as it would be fixed for all browsers. But the status quo is that there are tremendous amounts of clueless developers out there generating what appears to be bugs in other browsers - so it's in Microsoft's interests for these websites to remain broken and to deviate from spec.Anonymous
January 01, 2003
I'm sorry, but this post doesn't really say we're not going to be fixing bugs or moving towards better functionality.
The first three paragraphs really capture the entire point of this post.Anonymous
January 01, 2003
> I'm sorry, but this post doesn't really say we're not going to be fixing bugs or moving towards better functionality.
It indicates that you are probably not going to fix certain bugs:
> We feel it is vitally important for web sites and applications that worked with yesterday’s IE work with today’s IE, and continue to work with tomorrow’s IE.
There are bugs in Internet Explorer that, if fixed, would break some websites. The deviation from spec. I noted earlier is an example of one of them.Anonymous
January 01, 2003
Hey, that's sweet - they've started deleting comments! And all I did was point to the fact that the US law requires the owners of websites to make them perfectly accessible to people with various disabilities and that MS is liable for new lawsuits because their pathetic excuse for a browser doesn't really like pages that are made according to standards because it's so full of bugs it's hard to make it interpret valid HTML+CSS.
Go, Microsoft! Censorship über alles!Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Bruce
"... moving towards better functionality"
If by this you mean adding (say) tabbed browsing or RSS/Atom feed reading support into the browser app, can we hope that this will come after you have at least matched the standards support already achieved by Gecko and Opera?
If you really do have to manage with limited development and test man-hours, then it is core capability that has to come before the consumer-facing bells and whistles, however necessary it may appear to play 'catch-up'.
"we have an incredible number of different users and developers using IE in many different ways ..."
You've had a couple of really good suggestions in these comments on ways to keep the browser product both backwards compatible, and standards-compliant and secure going forward.
IE (the browser product) can never function as a 'universal canvas', so don't go there. The features required by those delivering convincing web applications are properly the province of custom hosts for WebBrowser and MSHTML; for example, customers of our Zeepe rich client framework are wiring together and deploying some really complex and powerful systems of the sort that cannot (and should never be allowed to) run in the browser.
Just my 2c.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Well.
It would be nice if Microsoft would actually stick to it. For instance, patch MS03-015 has broken IE by adding the apostrophe character to the set of "unsafe" URL characters. It escapes me how a character in a URL can be "unsafe" (except for the different meaning used for that term in RFC2396), and why server programmers all over the world should change their URL-generating code to workaround a bug in IE.
To make things worse, the problem only occurs when the URL triggers content to be passed to an external plugin (such as Acrobat).
BTW: the problem could be trivially solved by IE escaping the apostrophe as "x27" before passing it on to whatever considers it "unsafe".
And yes, there is an open support case about this problem. For almost a year now.
Best regards, JulianAnonymous
January 01, 2003
This biggest sin of the internet was to put the name of the browser in the HTTP protocol. This invites browser oriented code instead of standard code.
I call here all the browser manufacturers: stop identifying, just tell the version of each protocol you implemented.
Site builders must use a Validator to make their site standard.
If C++ compilers behaved like browsers, one couln't port any C++ code!Anonymous
January 01, 2003
Isnt this what doctype switching is for? You have standard compliance mode (correctly implemented css, html) and quirks mode (backwards compability for html, css).
Fixing the bugs in standard compliance mode will not affect old websites, since they probably dont have a standard compliance doctype.Anonymous
January 01, 2003
> I call here all the browser manufacturers: stop identifying, just tell the version of each protocol you implemented.
This isn't realistic. The User-Agent header is there so people can work around bugs in particular implementations. Nobody is perfect, and it's very short-sighted to not allow for a small margin of error.
The real problem is that once these bugs were identified, the browser developers didn't fix them.
> Isnt this what doctype switching is for? You have standard compliance mode (correctly implemented css, html) and quirks mode (backwards compability for html, css).
Unfortunately, "standards compliance mode" is far from perfect, and even people who trigger this will often rely on bugs in Microsoft's implementation.
In the past I have suggested that Microsoft pay attention to a HTTP header that turns on a spec. conforming mode - which is similar to the doctype switching, only better.Anonymous
January 01, 2003
Jim: what about the millions of people whose sites are hosted by an ISP, or a webspace provider? We cannot monkey with HTTP headers because we simply don't have access. We can only upload static pages. Any conformance control has to be in the source document.
Not to mention what happens if you obtain a document from some other protocol. HTML, while most often used with HTTP, should not be tied to it, nor vice-versa.Anonymous
January 01, 2003
> what about the millions of people whose sites are hosted by an ISP, or a webspace provider? We cannot monkey with HTTP headers because we simply don't have access.
That's what meta http-equiv is for.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
> As a producer of content I sure do hate writing duplicate code, but I also hate the idea of being allowed to do nothing more with my content than what the W3C thinks appropriate.
The W3C generally include methods for extending their work. Can you give an example of how the W3C is holding you back?
> Those of you who quickly dismiss the innovation of Internet explorer... are throwing a lot of baby out with the bathwater IMHO.
Hey, when Microsoft actually offers useful stuff, I don't complain. It's when they do it in a non-standard way that causes problems that I start to criticise. For example, proprietary CSS properties that do new things I would not criticise if they used a prefix instead of polluting the global namespace. Mozilla uses a -moz- prefix. KHTML uses a -html- profix. Opera uses an -opera- prefix. Internet Explorer doesn't use a prefix, forcing future specifications to either copy Microsoft no matter how badly designed it was to begin with, or break things, or use a less intuitive property name for the standard way of doing things.
> As a consumer of web content I want to be able to completely control how I view a web page. I want readily available tools to on the fly wipe-out out wherever I don't want to see or to be bothered with. Obviously, some content producers consider that a Internet sacrilege. Ultimately it is my opinion that the W3C is listening to more to them, than to me and therefore I find them a greater threat to the Internet I want, than the "evil doers" at Microsoft who do not strictly obey their standards.
Microsoft employees were part of the CSS working group that published the CSS specifications. You can't criticise the W3C for their user-oriented stance without criticising Microsoft for the exact same thing.
> PS I'm not a professional (or even schooled) programmer, so please no critiques regarding my incredibly sloppy code, or any other mistakes in precise literary "syntax"
I'll limit myself to one comment: I would take your comments regarding the specifications more seriously if you had not used incorrect syntax in your web pages. All that says to me is "I haven't read or understood the specifications I am criticising".Anonymous
January 01, 2003
We need to move forward. The sites that don't work in standards compliant browsers are in the minority (otherwise no one would use Opera, Safari or even Mozilla) so therefore it's your duty to help move the web forward by supporting new standards and allowing people to push the limits of the web. IE is a sad call from the late nineties when it was a pioneer, it's become a laughing stock and that's a real shame.Anonymous
January 01, 2003
Most of Microsoft's CSS extensions were created before the -whatever- convention came about, so I wouldn't blame them too much for that. I remember early builds of Mozilla supported the "opacity" property long before it was finalised.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
You mentioned this as one mitigation of compatibility issues. This one needs work. IE6 has some real problems with this feature. Pages that validate, and that look and act as expected in IE5.x and Mozilla, will break utterly and bizarrely in IE6 when a "strict switch" doctype is used. We have seen this so much since IE6 came out that our development rule is not to use any doctype statement which could put IE6 into this very quirky mode.
Recently a technical writer came to me with such a page. Looked as desired in IE5.x, the code validated and I confirmed the layout in Mozilla. IE6 displayed the layout in a way hard to describe without symbolist poetry. As it turned out, Dreamweaver had helpfully added a strict switch doctype.
Once we deleted that, all was fine in all test environments.
BrettAnonymous
January 01, 2003
Dave Massy explains IE's compatibility choices...Anonymous
January 01, 2003
sigh it's simple, if you want the web to move forward you have to sacrifice some compatibility for the sake of correctness. However, there's no point in getting rid of backwards compatibility if it doesn't interfere with published standards.
I'm sure that a lot of people would be very happy if we just removed the backwards compatibility that conflicts with the standards and left the rest in - that seems to be the way of the other browsers, I can't see any other mainstream browser that forces standards they all have some backward degree of compatibility.
So please, move the web forward, support the standards, you only have to drop compatibility if the standards conflict with the current situation.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I agree with "Dave".
The backwards compatibility ain't the problem per se. But when such compatibility conflicts with current standards, it has to go.
There might be a few intranet-applications that rely on the IE-bugs, but catering to those is throwing good money after bad. Every serious web-project right now spend up to 30% of their time applying fixes to various MSIE bugs - time is money - ergo: MSFT cost a lot of businesses a lot of development money because of their lax support for standards.
MSIE is turning my hair grey, is it our fate then to always have an old dinosaur that make our lives complicated? It used to be NS4 now it is MSIE6?Anonymous
January 01, 2003
How many of the websites out there, with DOCTYPEs that trigger standards mode, don't actually work with Opera, KHTML, Gecko, and a hypothetical better IE6? 1%? 0.1%?
I don't think anyone seriously expects IE to break support for DOCTYPE-less sites, but a lot of us would like you to finish what IE6 started.Anonymous
January 01, 2003
>""<Anonymous
January 01, 2003
In my opinion, there is one WWW and there should be one standard. Imagine if car manufacturers hadn't agreed on the mechanisms for operating a vehicle. You'd have to learn how to drive a car all over again everytime you wanted to drive something made by a different company. This would be frustrating to consumers, and I think the same principle will inevitably apply to IE. Whether anyone likes it or not, the computer proficiency of the average individual is steadily rising. As more people grow wise about options other than Microsoft, they'll see benefits with the other options and MS will be forced to compete on a level playing field. People will want standards-compliance, and if MS wants to keep customers they'll have to offer it. Of course, this requires not being forced into a browser by your operating system, but it looks like MS's stranglehold on the OS market is quickly loosening. I think the day will come that Microsoft is forced to innovate on the same playing field as the rest of the industry. That's when we'll see if they really can make the best software out there anymore.Anonymous
January 01, 2003
I think IE would be going along the right track to maintain it's current behaviour for pages that don't specify a doctype, but why are we STILL waiting for standards compliance in strict mode? If a page says it's html4 or xhtml then treat it as such - if it breaks, the author can either fix it, or remove the doctype declaration.
Fix the css implementation, and I'll no longer have one of the key reasons I have to convert people to Firefox. Although I prefer non-Microsoft solutions, I really don't care what my users have, so long as it doesn't make life more difficult for me.
My tip of the day - drop the IE rendering engine, and build on top of Gecko; open source isn't something to fear ;)Anonymous
January 01, 2003
I work for local government. Some applications that we use internally require Internet Explorer and, if the IE team ceased their policy of maintaining backwards compatibility, these applications would need to be updated. This may involve internal development work or procuring new systems. Inevitably there would be costs associated with this and these costs would ultimately fall on the taxpayer. That is, you would have to pay for it.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
My original suggestion for a browser that operates in "lenient mode" by default, but which can be forced into "strict mode" while developing, is a generalization of the DOCTYPE thing.
A DOCTYPE is a switch on a page. What I'm suggesting is a switch in the Preferences panel that can say:
* Give me a big ugly error message if there's a problem with the page I'm looking at
* Just figure it out as best you can
The first option is useful for developers when looking at sites you develop.
The second option is useful when looking at other sites.
The general rule I'm trying to convey here is:
BE LENIENT IN WHAT YOU CONSUME
BE STRICT IN WHAT YOU PRODUCE
This has various analogs in other areas, but is particularly pertinent for web development.Anonymous
January 01, 2003
please, i've been waiting for your ie port to texas instruments-99 for years.. when is it coming? :(Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Calvin, that would be mega-neat, but I doubt it will happen any time soon; in fact, 2010. sounds like a nice year for Microsoft to release IE7 which finally supports transparent PNG images.Anonymous
January 01, 2003
um, unknOwn, did I suggest that the world was the US? I didn't mean to and I didn't realise that I did.
I don't live in the US so I've no idea why I would suggest that.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Why does this website not validate?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
It's great that when slashdot writes something that might give IE the slightest positive comment then you're pasting it on your front page, but when it's saying things against Microsoft it's just a useless site full of zealots.
If you don't like slashdot, never cite one of its stories, don't be selective.Anonymous
January 01, 2003
Erm that was meant for the other thread!Anonymous
January 01, 2003
Ken writes:
<em>
Is that hilarious or what? They can't even get an SSL certificate to work properly on their own bug tracking site. If you want compliance with standards use IE.
</em>
Uh, what are you talking about? Did you even read the cert's details? The cert's completely valid, it's just that IE doesn't support certs across multiple subdomains.Anonymous
January 01, 2003
<em>
It seems to me an update to IE that contained some fashion of a meta tag that can force IE to render in truly w3c compliant mode would be the simplist answer (as someone else has mentioned).
</em>
That's done already: it's called strict mode, and it's triggered by the presence of the appropriate !DOCTYPE in the page.
What I think would be best is if MSHTML rendering engine was forked into a strict version and a quirks version. The quirks version would be frozen at the place where IE6 is now. The strict version would have development continued upon it. This would have the carrot of supporting existing sites with the stick of not supporting newer features, forcing them to use standards compliant markup to take advantage of new features.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I really like Jim's idea. The only way to have complete compliance is one step at a time. For example, remember Microsoft's proprietary MARQUEE tag? That's pretty much been phased out.
If W3C could implement a header tag that would specify what version of their recommendations the page follows, then the rendering engine could work the way we want. As time goes on (e.g. 2+ years), we would have complete compliance with all W3C standards.Anonymous
January 01, 2003
Its not "backwards compatibility" its "backwards incompatibility". Its the freak extensions that professionals distain. Step 1: quit creating freakish extensions. Step 2: phase out the past garbage that pollutes the web. Then there will (eventually) be no issue with the "backwards incompatibility" that IE currently strives for and achieves.Anonymous
January 01, 2003
This post is just a silly excuse. MS ran so fast to get to the no. 1 spot in the browserworld, that they forgot to do a proper job. Now looking back, MS sees the mess they've created with IE (and Frontpage) and come up with the user as an excuse. It should be obvious that holding back the web is not good for the users, however, it's been said that for IE to change course, it takes time for the top to realise the new course is better.
Which brings up the question: why post this article here? You know it's not read by your users, it's read by developers. Look at the reactions. I can only say: "a penny for your thoughts" 'cause I'm wondering if you guys are reading the replies and thinking: "oops, we could we be wrong" or thinking: "they're just developers, who cares about them or their extra time spent tweaking for IE" or thinking: "... "Anonymous
January 01, 2003
when someone creates a web page he/she is NOT a IE user, even if he/she wants to. The code must be valid for all browsers!
Now finally the tides are turning... When firefox has say 20% or 30% market share nobody will create IE only pages anymore.Anonymous
January 01, 2003
.. is that Microsoft tolerates hobbyists who have no clue how to write correct HTML and punishes those of the pro developers who actually try to do the right thing - get the site working in Safari, Opera, FFox/Mozilla and IE...
And suprise - getting it to work in IE is always the hardest part..Anonymous
January 01, 2003
I have to disagree with those who say that supporting the bugs/nonstandard stuff is ok as long as IE gets better standards support.
By continuing to support bugs/nonstandard code, Microsoft is encouraging apathy on the part of sloppy website designers. Without any pressure to fix their sites, this tolerance allows a large part of the web to persist being inaccessible to any browser that doesn't go to great lengths to duplicate the numerous bugs and quirks of past IE versions. Thereby making the web inaccessible to the myriad of new devices that do not run some form of Windows+IE.
This is something that's not in the interest of a company that truly cares about the health and well-being of the web. This IS in the interest of a company who has less-than-admirable ulterior motives. Microsoft's action (not words in some PR pseudo-blog) here will determine which they are.
Since when is supporting old bugs a good policy? Bugs are bugs and should be fixed, not left to fester and encouraging sites to actually DEPEND on them. That is utter nonsense. The only reason that so many sites depend on them now is because MS has (intentonally) neglected for so long their responsibility of coding to the accepted standards of the internet. Why "intentionally"? Browser lock-in. IE-dependence on one hand, and needing a "fixed" version of IE involving paying for XP so you can get SP2? All too convenient for raking in extra profits.
The time to eliminate the bugs is NOW. The longer you wait, the worse the problem gets. Microsoft needs to take the hardline and just stop supporting them, if they are to remain true to this image they are trying to spin about themselves. Until IE just drops/fixes the bugs, websites won't wake-up and finally get fixed so that they use standard code, making the job of web designers easier like they've been longing for so many years now.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
I'm curious about something, Rick: what was wrong with your scripts before Macromedia broke them with AS 2.0?
Did you have regular, functioning scripts, or was there something unusual about them that made the AS 2.0 changes incompatible?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
quote:
As a recent StopDesign investigation showed that if Microsoft switched to XHTML, their bandwidth costs could be reduced by up to 62%:
URI: http://www.stopdesign.com/articles/throwing_tables/
That is such a wonderful and great argument! But I get the feeling that although this is a weblog where people can comment, the editors are not reading the comments, or not caring, because how could one argue with these kind of examples? They obviously can't, or only by using the enduser and their feedback as a bulletproof shield.
My question: Helllloooooooo? Anyone of the editors listening here? Care to comment on this? Probably not. Then why don't you shut this weblog off, or at least the comments, because this is ridiculous!!Anonymous
January 01, 2003
We, the IE team, have absolutely no day-to-day responsibility for how Microsoft.com, MSN, MSDN, Hotmail, or any other Microsoft website decides to code their pages. Even this blog is being hosted for us, and frankly we have better things to do than fiddle with the blog code.
If you click the "Contact Us" link at the bottom of Microsoft.com, you can get to a form where you send feedback to the people who actually work on that site.Anonymous
January 01, 2003
>>But there are so many hobbists not to mention the millions of families and friends that create web pages to inform loved ones.
--an increasing number of people are using msn groups, photo sites and pre-packaged blog templates to accomplish this far more effectively than doing it all on their own. There aren't that many html 'hobbists' and of the ones I do know, they are all quite capable of running their pages through a quick validation and 5 minutes of fixing missing tags before they upload.
>>the small businesses that use WYSIWIG programs to create their pages.
-- if someone shells out money to buy a WYSIWYG program I'd expect the professional company to make a professional program (even if its made for hobbists) that creates valid html.
quote -> Should companies and professionals create well formed HTML? Of course.Anonymous
January 01, 2003
Após ler artigo "How Microsoft can support CSS2 without breaking the Web", referenciado no The Web Standards Project, nem precisa ser muito anti-Microsoft para perceber o jogo cruel de Redmond. Segundo uma entrevista citada de Gary Schare, a Microsoft se...Anonymous
January 01, 2003
That post from before about darwin...Anonymous
January 01, 2003
Pour l'histoire de cette traduction du billet de Chris Wilson, voir mon billet prcdent.
IE et les Standards
Tout d'abord, je voudrais me prsenter. Mon nom est Chris Wilson ; Je suis le directeur de programme pour la...Anonymous
May 19, 2007
PingBack from http://s1mone.net/blog/2004/11/buguento-porque-quer/Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=15563Anonymous
June 01, 2009
PingBack from http://paidsurveyshub.info/story.php?id=26952Anonymous
June 07, 2009
PingBack from http://weakbladder.info/story.php?id=2632Anonymous
June 09, 2009
PingBack from http://hairgrowthproducts.info/story.php?id=578Anonymous
June 13, 2009
PingBack from http://fancyporchswing.info/story.php?id=2065Anonymous
June 15, 2009
PingBack from http://einternetmarketingtools.info/story.php?id=9419