Update: “not a bug, it’s a feature”! See below for more, but the gist of it is that it is right according to the HTML 5 specs, but not according to the HTML 4.01 specs…

The problem change

Firefox 4.0 beta — as well as IE and Opera — do not send name/value for input type=”image”; only .x and .y coordinates are sent.

Note this is when clicking the input image with a mouse. When navigating using keyboard, focusing on it, and pressing enter, then the name does get submitted.

Earlier Firefox, Chrome (latest) do send name/value, which is what we’d expect…

Example

This form submits using a GET so you can see the submitted name/value pairs in the querystring:

What does W3C spec say?

17.4.1 Control types created with INPUT says this for input type image:

When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where “name” is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.

The previous quote implies name=value should not be sent for input type=image

But 17.4 The Input Element says this as part of the input name attribute formal definition:

 name        CDATA          #IMPLIED  -- submit as part of form --

That implies the name should be submitted too, even for input type=image (and assuming that, then the value of the input should be submitted too, which seems to be confirmed by section 17.13.2 Successful controls in the spec, which notes: A successful control is “valid” for submission. Every successful control has its control name paired with its current value as part of the submitted form data set.)

So, I think Firefox 4 has introduced a bug…?

Update: not a bug

The bug has been updated and turns out that this is per HTML 5 spec, while I was comparing with previous implementations in Firefox and HTML 4.01 spec…

IE (and Opera) also only send .x and .y, so I guess they settled on that given most sites are probably still catered for/assume IE as the predominant browser…

Workarounds

One possible workaround is this, but ugly:

1. Detect the browsers to do this for (feature detection would be better…)
2. Capture the form submit event and find the button that caused this, or capture the button click event
3. Append a hidden input like this (jQuery example, assuming button is the button you have captured):

   $(form).append('<input type="hidden" name="' + button.name + '" value="' + button.name + '" />').submit();

If you’ve already been working around this for IE, as the problem has been there for ages, then apply this for firefox 4 too (annoying and ugly to do browser specific code, I know)

Third workaround: don’t use input type=image, use input type=submit + CSS, or button etc.

The quickfix

You can fix this by doing the following:

1. Type about:config in the Firefox address bar
2. Look for the setting called layout.css.dpi. The default value is -1.
3. Change it to 96

There may be a deeper problem; Firefox on Linux is a GNOME application and so uses the GNOME window manager settings. Kubuntu uses the KDE window manager, so the DPI settings for it do not seem to apply to GNOME and I don’t know where/how to set GNOME ones while running Kubuntu.

Some forums suggest a few things that have not worked. While the above change in Firefox has worked, ideally I’d like to change the GNOME settings instead. Anyone have any ideas on that?

Getting Firebug working properly, too

To get Firebug to work properly (YSlow 0.9.5b1 seems to stop it working, which is a shame):

1. Uninstall YSlow if you have it
2. Uninstall any existing Firebug
3. Install DOM Inspector if not already installed
4. Get Firebug 1.2 alpha (1.1 beta did not seem to work properly for me)
5. Restart as prompted

I tried to reinstall YSlow, but no joy. That’s a bummer as YSlow is useful. Until they fix it, you can remote to a PC/Mac running it or use a virtual machine of something that runs it!

Some additional thoughts/notes

The Mozilla Knowledgebase on layout.css.dpi says that the default of -1 means to use the OS dpi or 96, whichever is *greater*, although Kubuntu/KDE reports 96! Somewhere there is a higher value, but I am a bit new to Linux to know where to find that.

While I initially suspected this to be a problem specific to Firefox on Linux when I used the vector graphic application, Inkscape, as I was exporting an svg to a bitmap, I noticed that the dpi settings it reported was something like 116dpi. Inkscape is also a GTK application, so now I think that it is a DPI setting used by GNOME.

Unless someone knows how to set those things while using Kubuntu, I have to make my change in Firefox itself (and see what happens when the final version is released). A few forums and posts suggested things like running the gnome setting daemon at start up, using the KDE GUI for GTK settings etc, but none of those seem to make any difference. Any ideas anyone?

I can live with this for now (I just need to figure out how to get those ugly close buttons replaced with something else — anyone know how to get GNOME apps to use a different icon set or theme when running Kubuntu???)

I also had a post on the implications of that meta switch.

Well, it seems that the IE team have decided to change that decision, and decided that IE8 will, by default, interpret web content in the most standards compliant way it can.

The reasons cited were to match Microsoft’s recently published interoperability principles, and due to developer community feedback.

It seems that legal concerns may have also been a factor.

Rather than go through all those issues here, have a look at these for more information:

• Microsoft Spins IE 8 Rendering Changes, Microsoft Watch
• Principles and Legality, by Eric Meyer (see also the interesting comment by Matt Wilcox in the comments thread)

It certainly seems like a welcome switch. If nothing else, Matt Wilcox made an interesting observation in the link above, that if this happens, Microsoft will be able to get a good set of stats on who actually decided to opt out and go for the IE7 rendering mode, and this may help inform a better and more accurate decision for IE9.

Are there any catches, or is this a welcome decision?

Update: Looks like a whole new raft of features coming in IE8 — some of them are playing catch up with other browsers, while other things seem new. (Interesting that they are increasing parallel HTTP connections to 6 per host, not just 2. Hope other browsers do similar things…!) Are we finally seeing innovation with IE again?

The challenge they had was to find a way to “enable (and encourage) interoperable web development, but don’t force IE to break pages that work properly in IE today.”

They eventually settled for a <meta>-based “opt-in to the browser version I tested with” strategy.

What this means is that if you as a web developer want IE 8 to render according to their best implementation of standards then you opt in by adding a particular meta element into your HTML (or send down a similar HTTP header in the response). This is explained in an article in A List Apart.

In other words, for web developers trying to do the right thing they must pay a small “don’t-break-IE-web tax!”

Many prominent web developers and designers have been highly critical of this. But, ironically, will this actually be a positive thing in the long run?

Don’t break the Best-viewed-in-IE web

The IE team described their attempt as a “don’t break the web” approach. Judging by many reactions, it feels they are actually breaking the principles of web development.

And, in their own words they don’t want to “force IE to break pages that work properly in IE today.” In effect they are asking web standards developers to help them out so they don’t have to go and fix all their problems resulting from the IE-driven web which has slowed down web development and contributed to this current problem. (That is probably a bit harsh, as I can certainly understand Microsoft would be unable to fix all the issues in the various places where IE is used! More on that below.)

The lead of the IE team, Chris Wilson, seems to admit this meta switch is a hack but given a difficult situation for Microsoft, trying to support both standards and non-standards developers, this might be the best way to go about it.

So other browser vendors were encouraged to adopt this idea too. However, the guys working on WebKit (the rendering engine behind Safari) felt that,

We don’t see a great need to implement version targeting in Safari. We think maintaining multiple versions of the engine would have many downsides for us and little upside. The IE team is, of course, under different constraints and free to make their own choices.

– Maciej Stachowiak, Versioning, Compatibility and Standards, January 22nd, 2008

John Resig (author of the excellent jQuery JavaScript framework and an employee of Mozilla), also takes issue with

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 [IE's] 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.

– John Resig, Meta Madness, January 22nd, 2008

Resig also made an important point about how this decision was arrived at:

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.

– John Resig, Meta Madness, January 22nd, 2008

Ian Hixie, lead member of the WHATWG (the guys that started defining HTML5), and Google employee, was concerned that browsers would have to implement it, like it or not:

If Web authors actually use this feature, and if IE doesn’t keep losing market share, then eventually this will cause serious problems for IE’s competitors — instead of just having to contend with reverse-engineering IE’s quirks mode and making the specs compatible with IE’s standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call “anti-competitive”, or “evil”.)

It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking. Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they’ll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.

– Ian Hixie, Mistakes, Sadness, Regret, January 23, 2008

Chris Heilmann, a lead web developer at Yahoo suggests that maybe now is the time to try and mend the broken web; a large number of sites are now created by CMSs and now might be the time to explain, help, and contribute to fixes. “As most are built with frameworks and CMS and one of the main selling points of these was that the outcome can be easily changed in the future, how about proving that now?” A garganutan task it would seem!

(Heilmann also posted a link to this hilarious explanation of how this meta-switch problem has come about.)

Microsoft is in a difficult situation

Resig noted above Microsoft’s situation is not something to take lightly.

The following is perhaps one of the best articles I have read trying to explain Microsoft’s predicament. It is not by a Microsoft employee, but a lead web developer at Yahoo! (and way before the Microsoft buy-out bid!!). Here is a lengthy quote:

[Don't just consider webservers,] but … other forms of distributing HTML content. How easy is it going to be to configure a webserver, or add a meta tag to HTML documentation on CD? It’s not just a case of editing the HTML and reburning to the CD – what about making sure everyone who has the old CD now has the new one?

Compiled HTML is another source of grief – every chm ebook ever published relies on an IE renderer library to display its content. That content is authored and then distributed to many people. Again, the HTML editing is simple, but the actual redistribution of the non-broken version is a massive problem.

Consider also the number of Windows applications that use the Internet Explorer rendering engine as a component of the application. All the content and logic for those applications would need to be updated, and the application would need to be re-shipped to all the users of that application.

The point here is that web’s solution is remarkably simple, it’s a case of fixing the problem in one place.

…

Sure, redistribution [for the non-web server-based products that use IE] is just a link to a website to download an update. But every software product, every ebook title, every software documentation would need that redistribution. It’s not a couple of web pages any more, it’s the entire Windows platform, the operating system and all applications (including third party software) that would need updating.

…

This points to a grievous mistake on Microsoft’s part: integrating the browser (well, the rendering engine) as part of the operating system.

A change in the rendering affects not only web pages, but local documentation, software applications, even so far as the file-system browser Windows Exploring. They all use the Internet Explorer renderer. The moment that renderer fails, or decides not, to render the content it used to render – that is a problem Microsoft want to avoid.

– Mike Davies, Internet Explorer Reality, January 27, 2008

It may have indeed been a mistake of integrating the browser rendering engine, but I wonder if more fundamentally, Microsoft letting IE6 stagnate and not developing it into IE 7 until just a little while ago was a root problem. Maybe continuous, smaller and incremental updates could have let the pain be less than it is now? Hard to tell.

Legal concerns if Microsoft breaks IE?

It seems that occasionally legal concerns about breaking compatibility with new IE releases comes up as another reason for not being able to move as quickly on standards implementation as ideal. However, Mike Shaver (from Mozilla) questions the legal concerns, asking, “What would be the legal basis for a suit by a customer, given the provisions of typical EULAs which explicitly disclaim pretty much all warranty they can?”

Comments on Shaver’s post also notes that changes to their operating systems (XP to Vista for example) and application compatibility problems seem not to raise such solutions, by comparison, despite concerns raised by even the likes of the Korean government and their banks who had to tell their population to delay upgrading to IE7 (because they had developed to IE6).

Shaver is hinting that legal issues may not be a hindrance as much as made out to be (though other practical concerns might still be).

IE8 passing the Acid2 CSS test won’t matter for most sites

A little while back, Microsoft announced that some development version of the IE8 code was passing the Acid 2 CSS test.

This led to a lot of praise in web development circles that maybe finally Microsoft was moving forward. But there were those expressing cautious optimism, too.

And the latter are justified; IE8 Acid 2 rendering won’t matter for the vast majority of sites that are likely not to even know about this new meta switch.

Maybe it won’t be too bad in the long run?

Many have opined that maybe IE is getting less significant now and whatever it does won’t really impact the web that much; it seems to follow these days, rather than lead.

It may be that IE 7 is just about bearable enough that developers can get on with cool things on other browsers while giving half decent support to IE7 (and with the increasingly sophisticated JavaScript frameworks hiding away those IE deficiencies and limitations in most cases, this may make it even easier to bear with!).

On the other hand, Matt Wilcox, a developer who is also on the HTML 5 working group, had a really interesting perspective:

I think the new default of “stay as IE7 when no meta tag found” will enhance the uptake of web standards. Because every ignorant developer on earth is now going to be permanently stuck with IE7 rendering and behaviour. They will never get to use any of the new-shiny [features] of IE8 and above if they don’t know to include that meta tag. They won’t know to include that meta tag until they go away and learn about web standards.

– Matt Wilcox, Goodbye DOCTYPE switching, hello META targeting, January 22, 2008

Maybe this particular tax will actually trickle down? Or will it really bad for standards-based web developers?

Maybe none of this actually matters?

John Resig, in another post on the HTML 5 DocType found out that IE will render unknown doc types (such as the HTML 5 DocType) in standards mode now.

The HTML 5 DocType is simply this:

<!DOCTYPE html>

This means authors could start using the HTML5 doc type now for their HTML 4 documents.

The W3C Validator would fail though (I think), which may be problematic for some.

So would it be better to pay that little tax, or go for this DocType now?

This is a great step forward.

The IE team has come under a fair bit of criticism lately for not giving any information to the web development community about what is going on, and when the next browser will be available.

Their announcement that the next IE was going to be called IE8 was almost taken as offensive by some people, judging by comments in that blog post, as they wanted to know more useful details, such as when there would be another browser release and what would be in it.

The IE team said they will “release a beta of IE8 in the first half of calendar 2008″ but have not currently revealed further details on what other features to expect.

However, they promise to offer more details going forward. Hopefully we see some other much-needed things like various JScript fixes and better standards compliance, more CSS 2.1 — even some CSS 3? — implementations and fixes, in-line spell checkers, etc.

Now we just have to hope that IE6 goes away even more quickly! When that happens, the speed of web development should be what we would expect; less time battling browser differences and making unnecessary trade-offs and more time innovating on top of a somewhat decent baseline.

Here’s to hoping…!

Update: February 9, 2008: Looks like Mike R’s concerns in the comments below from a while back were warranted. It turns out that when IE8 comes out, you will have to opt in to get IE8′s standards compliant rendering mode. Otherwise IE8 will render as IE7, which will likely be the case for the vast majority of sites.

However, a number of other posts on this site make reference to this point and I end up repeating myself, side tracking from the point at hand. For that reason, and for the benefit of some readers not familiar with this issue, this post serves as a summary of those concerns.

IE’s dominance unquestioned

There is no doubt that IE dominates the browser market share, from 90 to 60% depending on your demographics. IE 7 usage is on the rise as Microsoft pushes it out more, but IE 6 is still dominant too.

Where did this dominance come from? Was it from good quality software back in the late 1990s when the dominance started? Maybe, but it certainly wasn’t the only (main?) reason: during the browser wars with Netscape, as ZDNet reminds us, in 1998, “the U.S. Justice Department won a major judgment against Microsoft for competing illegally against another browser, Netscape.”

Back in those days of the browser wars, Microsoft was quite innovative. For example,

• They contributed to HTML 4, for example.
• Microsoft’s proprietary conditional comments for example are ironically a good way to separate out all the IE-specific workarounds from the normal code
• They even created the XMLHttpRequest object (XHR) almost a decade ago — ironically it wasn’t until a lot later that it was used on the client side for AJAX. And, while they had used it in Outlook Web Access, it wasn’t until Google and others started using it on a large scale that this technology took off.
• IE 6 (a 2001 browser) introduced Doc Type switching so that if you declared the doc type in your HTML document (and did so properly), it would attempt to render according to W3C standards, not Microsoft’s own quirky implementations (known as Quirks mode). The importance of this one is not to be underestimated (it gave Microsoft a way of retaining backward compatibility while supporting standards rendering going forward).

Of course, both they and Netscape also made some now embarrassing choices, too (Netscape’s, blink and font elements and Microsoft’s marquee, for example!)

But IE’s victory in the browser war for itself in the short term has resulted in created collateral damage, and possibly self-defeat.

Innovation stopped after dominance

Since IE won the browser wars and came out with IE6 with Windows XP in 2001, that also seemed to mark the end of their innovation. To be fair, for its time, IE6 was the best browser around. The problem is, given the speed at which things change on the Internet, it is now the worst mainstream web browser for developers to deal with; web technology has moved on, but Microsoft barely has (on this front).

It wasn’t until the start of the Web Standards Project that this began to change as people started coming together pressuring web browsers to improve, asking things like Why should developers have to waste so much time? Why can’t standards such as CSS be used across all browsers without coding for each browser (that you know of)? Why prevent people using your site?

This growing vocal discontent and Firefox’s rise contributed to the reasons IE7 made some improvements in IE7. Chris Wilson, platform architect for the IE team noted this a while back:

… we prioritized IE7 around 3 things – security, end user experience, and standards improvements in the platform. When I look back at the work my team has done in the platform, we have done only these things. No proprietary features added, just standards improvements…. I feel that we’ve addressed the biggest problems and shortcomings from IE6 for web developers and designers… As I previously stated, our goal is to make the lives of web developers better by improving standards support in IE. I think we’ve done a lot in IE7 to do just that, and I’m looking forward to doing even more.

– Chris Wilson, IE and CSS “Compliance”, August 10, 2006

While IE7 is definitely an improvement, it is still a fair bit behind compared to other web browsers, from a development perspective. In addition, IE 6 remains prevalent.

(Its amazing to think how many problems IE6 has when one of they key focus points for IE7 was better standards support and there is still so much left to do to catch up with the others. If you follow some of the links to other posts, and read their comments you will see how vitriolic some people can get about this, as it is very frustrating for web developers.)

IE stifles creativity (or makes it harder)

While IE 6 stagnated (and IE7 offered only a few improvements compared to what is really needed), other browsers have carried on, making web development through “Web Standards” important and possible (IE6 has enough of the basics to make this possible). Web developers have tried to move on too, but IE has hardly budged, thus slowing down real progress.

Well-known web designer, Andy Clarke, and an “invited expert” on the CSS Working Group at the W3C (where a lot of the specifications for things like HTML, CSS, XML, XSLT etc are made), recently made the following point:

Along with web designers worldwide, I have been creatively stifled by Microsoft’s decision to allow Internet Explorer 6 for Windows to languish in the doldrums for so many years. With their significant market-share, Microsoft should have been at the forefront of technical development and standards support in browsers. That would have fostered an ever increasing focus on what can be possible using CSS. Instead Microsoft allowed their lead to hinder progress and web designers, developers, their clients and their customers have all suffered as a result.

– Andy Clarke, CSS Unworking Group, Stuff and Nonsense, December 14, 2007

In some cases it has stifled creativity, in other cases, it requires a lot of workaround which leads to excess code (and all the costs that are associated with that).

Rather than go into the technical details that plague the browser here, such as the multitude of bugs, lack of CSS support, lack of W3C DOM Support, here are some resources that do just that:

• Quirks Mode by Peter Paul-Koch (ppk) lists all sorts of browser incompatibilities
• Position is Everything to explain CSS bugs
• Gérard Talbot has listed numerous CSS bugs for browsers with IE topping the list.

What’s also interesting about Talbot’s page for IE7 CSS bugs is that it has a number of quotes and rants about IE’s impact on web development:

Until IE is reasonably standards-compliant you can expect no quarter from us. We’ve spent too much time designing web sites that will work for CSS and then work for IE. We’ve destroyed budgets, pissed off our bosses, irritated clients and made development more expensive because of [IE].

– a comment to Chris Wilson’s post, IE and CSS “Compliance”, August 10, 2006

This comment to another post from the IE blog was made back in 2004 and is unfortunately still relevant today:

I author to standards, it takes a few minutes to tweak things to get everything perfect in browsers like Firefox and Safari, and then ages to work around all of Internet Explorer’s bugs and shortcomings. The time to implement a decent XHTML Strict + CSS 2 design would be shortened by at least a third if Internet Explorer wasn’t so buggy. I have measured this personally across a number of projects.

… CSS 2 is over six years old, and Microsoft have had employees in the CSS working group the whole time…. Given that Microsoft are the world’s biggest software company, it looks very much like standards are deliberately being sabotaged. Is it any wonder web developers are starting to get royally pissed off with Microsoft?

– a comment to a post on the IE Blog, I love this browser!, IE Blog, July 21, 2004

Alex Russell, a prominent web developer and creator of the popular Dojo JavaScript toolkit highlights the pain caused:

Here’s a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don’t care. We don’t care how much it costs you. We’ve been cleaning up your messes for *years*. Those of us tasked with ‘just making it work’ have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that’s left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are ‘engaging with the community’? Fine. Fix your (expletive) browser. That’s the bar the IE 7 team needs to hurdle.

– Alex Russell, How IE7 Can Avoid Irrelevance, January 22nd 2006

“Economic Wastage”

Okay, so the above pie chart (from Marco van Hylckama Vlieg, a web developer working for Yahoo! Europe) is a bit of fun, but reveals underlying frustrations (and while maybe at the time the image was created some CSS layouts were frustrating enough to contemplate table-layout, I think for the past year or two that has not been necessary! Also, if any one knows what Firefox JavaScript space issue the image is referring to, please drop a comment!)

In a way, IE therefore has contributed to a lot of “economic wastage” that others bear the brunt of.

For example, there are

• Unnecessary trade-offs, such as reduced features, less or no accessibility considerations, limited cross-browser compatibility, extra code bloat, etc.
• Extra costs, such as hiring more web developers than actually necessary in an effort to deliver on time, or assigning more time to the project, or just accepting that this is how web development is done, not realizing it can be better if web standards formed the basis of web development.

These costs are borne by companies, organizations, and individuals, not Microsoft.

This results in wasted capital and a slow rate of evolution for the web.

Reading the comments from developers on some of the IE Blog’s recent posts, reveals just how frustrating web development has been at times:

• The First Year of IE7
• Internet Explorer 8 — this was meant to be light humor on how Bill Gate announced that the next version of IE would be called IE8 (a no-brainer?) but the comments revealed the real concern was lack of progress, features, insight into IE development.
• ECMAScript 3 and beyond — although this post is about a wider debate on ECMAScript, the comments reveal frustration at JScript (Microsoft’s implementation of ECMAScript, which we otherwise typically call JavaScript) and its numerous problems

The JavaScript 2/ECMAScript 4 debate is interesting in that another influential player, Yahoo!, has joined Microsoft saying they don’t like the proposed changes (proposed/supported by Mozilla/Adobe/Apple). At a recent conference at @media AJAX, Douglas Crockford said that amongst other things it was IE6 that was holding back real JavaScript improvements (because while it remains a prevalent browser, any changes introduced to JavaScript either won’t be backward compatible enough, or won’t help address fundamental security problems which IE6 in particular is vulnerable to. This is a big enough issue itself, which I won’t go into here.)

How Microsoft can redeem itself?

Microsoft can easily rectify the problem: they have the resources to put people into sorting out the issues if they really wanted to (they will when threatened by competition, as Firefox’s rise showed, but many still regard them as a monopoly and thus have very little incentive to move ahead significantly at this time).

On the plus side, they have people on board, like Chris Wilson, that generally get the grievances developers hold and wants to see progress on this front.

Aggressively supporting efforts like HTML 5, maybe JavaScript 2, etc, will be a chance to start afresh and provide decent implementation.

(Reading posts on HTML 5, there is much skepticism that it will happen in a meaningful timeframe in such a way that it will be used mainstream — not because of the slow standards-defining process (though that certainly may be part of it) but because of IEs dominance and slow movement in these areas.)

None of this is easy by any means, but it has taken some 5 years to get some progress from IE6 to IE7 and it still lags behind the others.

Vendor-specific implementation is okay, (maybe even encouraged?) but standards should form basis from which these extensions are made.

When IE 7 first came out, Microsoft said they would release more frequently, every three quarters to a year would be a new release. One year on from IE7 and the best we have is the announcement that the next version will be called IE 8 and growing frustration at how little information there is now coming out from Microsoft about any solid plans for IE 8.

So maybe their priorities, from a web development perspective, would be to

• Become more open and tell developers what they are planning and when for
• Actually fix all the remaining CSS and JScript bugs
• Complete HTML 4/XHTML 1.0 support (e.g. the <q> element would be nice, as well as the XHTML mime type)
• Provide far better CSS 2.1 support (maybe even start supporting some CSS 3 features)
• Provide far better W3C DOM support to make JavaScript development (and execution) more efficient

This is not a complete list, and there are all sorts of posts on the web and to the IE Blog with better lists, but you get the idea.

Here is one ominous warning for Microsoft of not doing so:

I sympathize with your situation, but you desperately need to get your seniors and peers to understand what’s happening, and to assign your team way more resources. IE is a first-impression MSFT product for most web developers, and yet you all continue to underestimate the dramatic spillover effect this poor developer experience has had and will continue to have on your other products and services.

Let me drive this point home. I am a front-end programmer and a co-founder of a start-up. I can tell you categorically that my team:

- Won’t download and play with Silverlight
- Won’t build a Live widget
- Won’t consider any MSFT search or ad products in the future

And the reason is because of IE – because MSFT disregards its most important relationship with us. Until this relationship is repaired, nothing else stands a chance.

Please fight the good fight and drive this point home in your org. Good luck.

– Anonymous commenter to The First Year of IE7, November 30, 2007

Do we ironically thank Microsoft for this mess?

In many regards, the evolution of the web has been slow, and we should have been a lot further down the line than we are now.

For example, HTML 5 should perhaps be a lot closer to reality, Accessible AJAX apps should be the norm, not the exception, CSS3 should be widespread, etc.

Finally, one thought: would this have really happened without IE’s problems? One can never know for sure. Were it not for the problems IE caused, could it be that the frustration that led to better awareness of web standards would never have been nurtured? Ironically, do we have to thank Microsoft for making our lives so hard that we now have some ideas of how it could be better?!

Image credits

• Internet Explorer Voodoo Doll, by chisa, posted on Flickr
• Rust in Peace, by dasbull, posted on Flickr
• Microsoft World Domination 99, by kelly varner, posted on Flickr
• HTML Cannot Do That, by Noah Sussman, posted on Flickr
• Time breakdown of modern web design via Marco van Hylckama Vlieg

Why?

Why is Microsoft doing this? They say that it is because “Microsoft takes its commitment to help protect the entire Windows ecosystem seriously.”

My opinion on this is that they are finding that those with cracked/non-genuine Windows are stuck on IE 6 and even though that is not Microsoft’s fault, the security holes in that browser gives a bad image for Microsoft.

I also wonder if they are doing this to challenge the rising popularity of other browsers such as Firefox and Safari.

Anyway, those are just my initial quick thoughts.

Its a good move

From a web development perspective alone, I think this is a good thing:

For web developers IE6 has long replaced Netscape 4 as the annoying browser to cater for given all its CSS rendering bugs and DOM deficiencies.

IE 7 is a vast improvement over IE 6.

The less people using IE 6 the better for them and for us web developers!

That being said, IE 7 is still not up to speed with CSS and DOM support as the other modern browsers but in my opinion requires far less alternative CSS rules for example.

Or is it?…

Or, is it a good move?

If Microsoft regains its dominant market share of a few years ago (approx 95%) will it just sit on its browser and not do much with it again, thus slowing down overall progress as before?

(I’ll expand on this last point in another post!)

To be fair, there are enough signs that Microsoft’s IE team is far more committed to standards support etc than before, with people like Chris Wilson and Molly Holzschlag and various others there who “get it.”

Its near impossible to predict the future, but another way to put the above concern is as follows:

What would I prefer:

1. The current situation with IE 6 so prevelant
2. Microsoft regaining its dominant near monopoly browser market share with IE 7
3. IE 7 replacing many instances of IE 6, but being a browser amongst a diverse ecosystem of web browsers all competing by using standards as a basis for innovation, not proprietary stuff as the basis (as was the case in the Netscape 4 vs IE 4+ browser wars)

I think I would prefer the 3rd option…