Ok, as several people wondered (in tweets and emails) what my stance on the whole IE8 malarkey is, first of all an explanation why I didn’t bother to blog about it yet:
- I was busy with more immediate concerns about my professional future
- Far too many people already blog about it, speculating this or that way and cross-link the same speculative articles over and over again. This will make it hard to find real information once we know the outcome of the dispute (and it is still a dispute as the rendering issues are only the tip of the iceberg). But hey, hits for their blogs = teh win!
- I am lucky to be on a mailing list consisting of a lot of very clever people who are involved in the development of a lot of the big JS libraries and are part of companies that will have an impact on Microsoft’s decision and there is a full out email avalanche going on there.
- It will be damn hard to beat Katemonkey’s explanation of IE8 and lemurs anyways
Now, to sum it up in some short words: Microsoft is in a pickle, or let’s say in between the devil and the deep blue see
The Devil – all the old badly developed sites
The biggest issue for Microsoft is that they “don’t want to break the web” – or in reality all the web sites that were built believing in the promise that Microsoft or WYSIWYG products create future-proof code. These are a part of the web – in a lot of cases the part that is behind a firewall and start with “intranet.company”
The Deep Blue Sea – standard aware web developers
The other big party Microsoft tries to make happy are the standard aware web developers. You might now say freaks and why bother when the enterprise market works happily without it but let’s remember what the benefits of working with standards is:
- interoperability
- option to convert to different formats in the future
- making web development a more mature job, and not something anyone can hack together – which also makes it easier to assess the quality of applicants and hire them faster
- ease of bug tracking and QA (you know how it should work and can find out what caused it not to)
- ease of maintenance, as developers see what is going on and don’t have to try to understand what the earlier developer has done, fail in doing so and just slap some more code on at the end to make the product work.
Microsoft’s relationship with these people has never been easy but improved a lot in the recent months. The IE team took research found on the web to fix CSS problems of IE6 in IE7 and have invited experts to help them make IE better. The problem that still persists is history. Let’s do a quick time travel:
Pitch situation (around 2003)
Freaky, border-line hippie small agency: Hello Mr. Moneybags, you asked us for an offer for a web portal for your company that covers both the outside world and your employees’ needs. Here’s what we came up with. You might see that we did some extra time padding to make sure we follow web development standards and test on different platforms to ensure that everybody in and outside the company can use the system.
Man in suit: Hello Mr.Moneybags and thank you for asking us to provide you with a new e-portal covering intranet and internet with CMS and customer care features. Well, you are in luck! We will be using industry leading systems by Microsoft and Oracle to give you a system that ties in seamlessly with your current infrastructure needs. Let me see that computer, ah! Internet Explorer. You’ll be happy to know that what we give you will work with this and with your Outlook solutions! And the best is – we have fixed prices for initial delivery and a very good customer care program (but that is an agenda for another meeting in the future).
What did you think Mr.Moneybags went for?
OK, so let’s help Microsoft with their problem
Now we have a situation where the proposal is to add another META element to ensure that these problems don’t happen. This doesn’t seem much, but it is once again delivering extra work to please one browser on the internet and follow the standards other vendors have much less problem adhering to. Let’s not forget that we already did that when the other MSIE’s came out:
- We do use DOCTYPE switching and don’t use an XML prologue for XHTML (oh, wait, we don’t do XHTML as MSIE doesn’t support it)
- We grumbled but we agreed to use conditional comments as the most useful way to patch for MSIE
- other browser vendors started supporting MSIE-only solutions like innerHTML and clientWidth not to break sites that were built for IE only. Isn’t that enough good will?
Then we got the carrot of “IE8 supports Acid2” and went “Wahey! No more hacking for IE in the future” and got the cold shower of this proposal. Again we were let down.
But what about the broken web?
The broken web is there because salesmen and product descriptions promised something they cannot deliver – that by sticking to a monoculture you can save time and money. History proved that the brave new world of interoperability of products from one single company does not happen. People have the choice of different operating systems and browsers and they should have that. Many councils and schools in Germany for example completely moved to Linux solutions in order to save money – and it works.
I get the distinct impression that the broken web is not as big as we make it to be and if it is then it really is broken because it was built on wrong assumptions and developed with shortcut after shortcut sacrificing maintainability and interoperability.
How many intranets, expense systems and room booking software did we have to use that did not only work in IE exclusively but also were borderline unusable as they considered options a nice to have rather than a decision to make? How many intranet systems are inaccesible to non-JavaScript users, keyboard users or blind people? Yes, it is hard to make a company change these systems, but for Pete’s sake, let’s get rid of this cruft!
Web-Appers and Microsoft unite
And this is what I think is the main step forward: instead of trying to accommodate for a broken web that should have been ditched years ago we should offer patches, tutorials, coaching and mentoring for maintainers how to upgrade these systems.
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? In the last few years we shifted more and more away from web site development to web app development and I have yet to see a big impact on the enterprise market. I see a lot of cool RoR tools for the lower and middle market, but nobody takes on Mr.Moneybags and counteracts the promised of the men in suits.
So please, Microsoft, launch a “make your systems more secure, future proof and available” campaign with fixes, patches and good information and I am happy to chip in. I am much less reluctant to cover your butt once again though just to prevent you from having to admit that things change. You ditched all DOS applications when you simulated it in more modern windows than 95, why not show the same power of decision making now?
