[Advert: Support Joe Clark's Micropatronage Project - support accessible media research]

Syndicated feed for Web Standards

Weblogs: Web Standards

For future growth of the Web into a pervasive medium, adhering to webstandards is a fundamental step.

Web Standards links

Atom Feed for this links blog Link blog feed

Sunday, January 27, 2008

Internet Explorer Reality

Jeremy Keith characterises my position on Internet Explorer 8's meta tag switch as simply [not] facing up to reality. That would be understandable coming from the blue-beanie guy or Eric Meyer. But not from someone advocating that the default setting should be IE8's renderer. For two reasons:

The answer to the first question is fairly obvious - no. The second, whether it solves Microsoft's issue, is not as straight-forward.

Standards compliant default

Both Jeremy's and my proposal are based on the principle that the browser gets standards-compliant rendering by default. No meta-tag, and the Internet Explorer 8's rendering engine gets used.

As such, my and Jeremy's proposals achieve the same goal: standards markup is rendered by a standards compliant renderer without having to ask a second time for permission.

Except Jeremy places a burden on Microsoft's locked-in clients - they have to adopt a meta-tag to ensure their documents continue to work.

Breaking Microsoft's customers

Jeremy's suggestion is that Microsoft can now provide their customers with a ludicrously simple answer to any future problems. All they have to do is add a meta element to their documents (or set up their server to automatically output that header).

And with this Jeremy feels that the chasm between IE7-dependent rendering and IE8 can be bridged. It does in theory, but in practice it cannot be done without enormous expense and great difficulty.

Non-disclosure

One of the problems of non-disclosures is that when a disclosure is needed, the core information is released without the supporting information. The supporting information is what makes or breaks any proposal. And what is clear with this week's buzz of activity is that there are a lot of unanswered and unresolved questions because the necessary information is still held within a Non Disclosure Agreement.

That means Jeremy, blue beanie man, myself, WaSP members, as well as the entire web standards community are playing a game of magic mushrooms. We are all in the dark about the issues and problems Microsoft are really dealing with.

We don't know the issues and ramifications of our proposed solutions because Microsoft haven't told us the whole story.

Assuming a web server

Jeremy's solution covers HTML documents delivered from web servers - since that conveniently covers Internet and Intranet users (as well as Extranet users, for additional brownie points). What it doesn't cover, or takes into account, is HTML documents that are not delivered from a web server.

And of course, Microsoft should have given us this pertinent information, whether it's a factor or not. But they didn't. We are left to assume, like mushrooms in a dark room.

The veil of non-disclosure

Now if Eric Meyer failed to win this particular argument, I doubt it was because of a lack of understanding of web standards, or a lack of persuasion. I suggest that Microsoft found that Eric's solution didn't solve the problem Microsoft are addressing. There's no indication whether Eric knows the real reason why Microsoft found that solution unacceptable, or whether he does but is prevented from saying so - it's irrelevant either way. The problem is clouded by Microsoft's non-disclosure way of working.

Breaking Microsoft clients

Microsoft have disclosed a portion of development issues: mainly they need a solution that doesn't break their existing IE-only Intranet clients. But, Jeremy has assumed, thanks to a lack of pertinent information, that breaking means from a web development perspective. That assumption has neither been established or refuted.

And yes, the Microsoft definition of 'break' is probably a lot larger and complicated than Jeremy Keith's. We don't know entirely, because Microsoft are hiding behind an NDA.

Changing the unchangeable

Jeremy considers webservers, but not 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, and then everyone then receives that one change with no massive redistribution effort. The ebook providers, the software authors, the software documentation authors - all run into massive problems.

Any application that uses the internal renderer as either a viewer or an editing interface is going to break because of Microsoft's browser update - particularly if they follow Jeremy Keith's recommendation.

Sure, redistribution 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.

Too close to the metal

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.

Consider the software you've been using for years to collate all your personal expenses. What happens, when you install IE8 with Jeremy's preferred option, and that breaks. There goes your personal tax returns process. Hopefully, you kept all the receipts in a shoe box rather than throwing them away after you'd scanned them into your software.

Software doesn't have to be web based to make use of the IE rendering library. And that software will break, regardless of whether it needs an internet connection or not.

Legal implications of change

Even if the redistribution problem could be solved, there is still the very murky question of the legal implications of making a change to existing documents.

A year ago Apple unlocked the 802.11n features that were already present in the Core 2 Duo Macs. But they charged $5 for the patch instead of offering it as a normal upgrade. The reason for the charge:

The Core 2 Duo Macs weren't advertised as 802.11n-ready, and a little law called the Sarbanes-Oxley Act supposedly prohibits Apple from giving away an unadvertised new feature for one of its products. Hence, said the Apple rep, the company's not distributing new features in Software Update any more, just bug fixes. Because of Sarbanes-Oxley.

Even though Microsoft has a long history of scorning legal tenents, Sarbanes-Oxley is one Act they will not risk contravening. This Act is largely a defense against unscrupulous management of companies, to prevent another Enron.

How does this affect HTML documents? If those documents are used as part of a reporting mechanism within a company, any system that contains contracts, policies, terms of service, financial information, personal information - the information that's the lifeblood of a company, the Sarbanes-Oxley Act legislates a process of how that document can be edited.

That legislated editing process makes inserting a single meta tag into an HTML document an onerous task. Even if those documents were delivered from a web server, there's a legal grey area whether the webserver is allowed to change even the HTTP headers without needing to go through an auditing process.

A simple change, according to Jeremy Keith, but one that opens a cacophony of implications, and may prove practically impossible to widely implement. Companies - Microsoft's most important customers - are likely to be very vocal in what they see as Microsoft forcing them to undertake a difficult and expensive process. Microsoft cannot afford that.

Fear, Uncertainty and Denial

I'm very much aware that this post could construed as FUD. Certainly, there's fear, the fear that Microsoft will break the web in favour of supporting their customers. There's uncertainty over the real facts and issues, since those has been cloaked by Microsoft through Non Disclosure. And there's doubt, I do not believe Microsoft are doing things in the best interests of web standards.

FUD relies on vague information to paint a bad picture of a competitor, as a tactic of disinformation. It's a tactic well employed by Microsoft, so it would be ironic for me to be successfully accused of FUD against the masters themselves.

As it stands, Microsoft's closed negotiation stance, not speaking clearly with an unfiltered voice is a disservice to themselves and a persistent danger to web standards developers. The limited information, the secretive consultancy, the - what seems like - scant disregard of the value of open standards. These are qualities that are not conducive to solving problems or proposing solutions.

Mushrooms in a dark room

Jeremy Keith, in arguing for the default IE setting should be is its standards-compliant rendering, has either accepted Microsoft's open statements at face value, or ignored the implications of such a change. He's proposed the same solution as that which Eric Meyer failed to convince Microsoft. That alone should trigger the warning bells - proposing a solution that has already been rejected.

It stands to reason there are details and issues that Microsoft have deliberately not mentioned. That would be the practical logical finding. Microsoft doesn't have a history of tell-all, and Eric Meyer is one of the best negotiators in web standards development.

If there's anything that says [not] facing up to reality, it's the idea that IE8 rendering standards mode by default is actually a practical solution for the problem Microsoft is trying to solve.

Towards resolution

We're not here to solve Microsoft's problems. Microsoft's solution is for web standards developers to carry the burden of its browser failings. That is unacceptable for us, as web standards developers. Web standards development is browser agnostic. For open standard to flourish, we have to be independent of the browser vendors.

This is not about punishing users of Internet Explorer. We didn't willingly put users in this position, Microsoft did. We are not punishing users by using standards compliant markup. If anything, Microsoft's customers, with their IE-only Intranets and websites - they are the people who are punishing users. We web standards developers are not to be blamed for this mess.

Backwards compatibility

Lets make one thing clear: Internet Explorer 8, in its currently described form is not backwards compatible. Internet Explorer 8 is really two browsers, Internet Explorer 8 and Internet Explorer 7 (regardless whether they are just libraries or standalone software products).

It's clear that Internet Explorer 8 is created just to appease web standards compliant developers. There's no actual value in the browser itself. There's no upgrade path for users, since the vast majority of sites will render in the IE7 engine.

What we are seeing is a Microsoft that's created two standalone web browsers. But unwilling to come to terms with the devastating predicament the older one is causing. Politically, having two browsers would be seen as a defeat of Microsoft's web strategy - and yet, this is what we are starting to see: Microsoft paying the price of proprietary and de facto standards.

Hence my position of rejecting Microsoft's proposal and remain steadfast in delivering standards compliant markup doesn't mean punishing users. It means the responsibility of protecting Microsoft's users falls back to the very organisation to which it belongs - Microsoft. If they believe they cannot protect their users in any other way other than burdening us developers, then they need to openly and rationally explain why.

Failure of de facto standards

It's the beautiful, and inevitably fatal, logic of pushing the browser rendering engine down into the guts of an operating system. Fatal, because it relies not on open standards, but an ad-hoc and essentially sloppy approach to markup. Markup Microsoft has committed itself to supporting - and one it now, begrudgingly, has no choice but to support.

It's ironic, that of all the major browser vendors out there today, only Microsoft is the one that's still building on the same codebase that they delivered during the browser wars. Every other browser has either started from scratch from the ground up (Firefox and Opera), or created a browser after the browser-wars (Safari). As such, all three have benefited from not having to support Microsoft's excess baggage. And Microsoft being dragged to a complete stop because of it.

This is Microsoft's browser-war victory biting them in the ass.

Tuesday, January 22, 2008

End of line Internet Explorer

The biggest barrier to Microsoft adopting web standards is Microsoft's own clients, or rather Microsoft's promise to them of backwards compatibility. They have a plan to solve this, but it demands that web developers sacrifice the future compatibility of their sites.

Microsoft's proposal is for web developers to opt-in to Internet Explorer 8's standards mode by adding in a new meta tag (or HTTP header). The benefit to Microsoft is that their clients haven't got to do a single thing - but web developers using web standards have to update all their pages to take advantage of standards compliance in Internet Explorer 8. (and again and again when any new version of a browser gets released with this 'feature').

No.

Future-proof

One of the benefits of web standards is that you author a page once, and it never has to change again for the rest of its lifetime. When a new browser is released, the pages on the Web continue to work. That is why we use web standards. Its a fundamental component of the web - and it should never be betrayed.

Microsoft's approach is to promise their customers backward compatibility regardless of the quality of their markup. From their perspective, allowing already broken pages to appear broken in a new browser is unacceptable.

Microsoft have no one to blame but themselves for the predicament they find themselves in. Many software products have gone down in history for the abysmally low quality of markup it generates. Unfortunately for Microsoft, their browser has had to seamlessly handle the bad markup generated by their own web publishing tools.

Three and a half years ago I wrote about the cost of supporting non-standards, pointing out that Microsoft could not continue building on top of its existing Trident rendering engine. Their Program Manager noted that major standards changes to the Trident engine would be prohibitively expensive because of the levels of regression testing needed to ensure that the rendering engine would not break on their self-inflicted markup swamp.

At a point in the future, Microsoft will realise the folly of continuing development of the Trident rendering engine, and realise that it will not be economically sustainable. They will realise that to support web standards properly, to the current levels of Firefox, Safari and Opera, they will need to wipe the slate clean and start a new code base.

Our documents will work on this new code base - if Microsoft's commitment to open standards is to be believed.

The Netscape plan

Netscape Navigator 5 is the browser that everyone was waiting for, but never arrived. It would be the pinnacle of browser development. It would be the death blow of Microsoft's Internet Explorer.

Except it never arrived. It died a prolonged death. It died because the code base - like IE's codebase today - was so full of cruft in trying to deal with horrible markup, it proved insurmountable in developing the next browser version.

Netscape killed Netscape Navigator 5, and in its place created the foundation of what we know as Firefox. They started from scratch, built in support for web standards from the very beginning. The product matured from Mozilla milestones to official Mozilla releases, to skunkworks projects, to Phoenix, to Firebird, to Firefox.

Firefox lead the way. It inspired web developers and practically encouraged web standards. It rejuvenated the web, made it fun again.

As Firefox grew, Internet Explorer 6 was in stasis. Microsoft had crashed into the wall which was the prohibitive cost of continued development of their browser.

Firefox forced Microsoft to reinvest in Internet Explorer. It forced Microsoft to compete, forced it to play catchup. Firefox was a direct threat to Microsoft's hold on the web. It forced Microsoft to compete on the basis of web standards compliance. Four years later and Microsoft are still playing catchup.

There's a lesson for Microsoft to learn in there.

Microsoft would do well to learn the lessons of Netscape and realise that Internet Explorer is functionally incapable of both preserving backwards compatibility for its half a billion clients, and supporting web standards. Something has to break.

Microsoft need to put Internet Explorer into maintenance mode.

Blame shifting

Microsoft have got themselves into this mess by their own misguided strategy. By promising backwards compatibility, they've compromised the future direction of the browser. They've compromised Internet Explorer's capability of challenging Firefox in any meaningful way.

What particularly annoys me from today's news about Internet Explorer, is Chris Wilson's blame shifting. He puts the blame for Internet Explorer's failings on web developers. For example:

The answer is that developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in "standards mode," even though it didn't follow the specification - because they'd already made their content work with our model.

We web developers are now being directly blamed for supporting Internet Explorer! Microsoft released an inadequate browser and left us to deal with the problem on our own. Now Chris Wilson has the audacity to criticise us for trying our best to sort out the mess his team created.

We realized that "Don't Break the Web" should really be translated to "Don't change what developers expect IE to do for current pages that are already deployed."

It seems that Microsoft's promise of backwards compatibility is an empty one.

Heaping the blame on web developers is unfair. This situation is entirely of Microsoft's own doing. And they did nothing about it until Firefox became a serious threat.

What those two quoted statements really say is that web cannot rely on Microsoft for standards compliance, backwards compatibility or future compatibility.

And that alone, is sufficient reason to reject their meta tag proposal.

Opt in

Building a standards compliant website involves well-formed markup which reflects the structure of the content, Cascading stylesheets to suggest a presentation and layout, unobtrusive JavaScript for behavioural enhancements.

With those elements in a site, you've effectively opted into a standards compliant universe.

Microsoft have now put a tollbooth on the web standards compliant road. The payment is a meta tag that says, "Yes, that is a webstandards compliant page, I really really really do mean it". And that meta tag is only useful for Internet Explorer 8.

Effectively you have to ask Internet Explorer 8 for permission to render your standards compliant page in a web standards compliant rendering.

Microsoft's customers, after years of emitting heaps and heaps of malformed and ill-informed markup have to do absolutely nothing.

Microsoft are demanding that we web standards developers favour them with time, cost and effort, while they continue to abrogate their responsibilities to their half a billion clients.

Browser sniffing

The meta tag triggers off a behaviour in Internet Explorer 8. That's a form of browser sniffing - a piece of code that triggers off a certain reaction based on the user agent.

We've already realised the massive cost and downsides of browser sniffing, and there's only one answer worth giving for these techniques: Never.

Contract and Responsibilities

Web standards is a contractual responsibility. Its a promise from web developers to write pages that conform to the W3C Recommendations. Its also a promise from browser vendors to render pages that meet those standards in the correct way according to the meanings and justifications of those standards.

Its a clear separation of responsibilities, and one that has been working well with Firefox, Safari and Opera.

Microsoft on the other hand are now expecting us web developers to carry the burden of their responsibility. Instead of Microsoft abiding by the responsibility of rendering pages according to the open defined standards, Microsoft are intent on making standards-based pages second class citizens.

Standards compliant pages must always carry a Microsoft passports that identify the holder as a standards compliant page. Sounds like a ghetto to me.

That's what we are being asked to do. We're segregated from the rest of the Web, and forced to carry identity documents that prove we are standards compliant, and earn the dignity to be rendered in a standards compatible way.

If you have a low quality website, you have to do nothing.

Web developer benefits

What are the web developer benefits? I don't see any. I see us sacrificing the benefit of future proofed pages. I see us struggling under the weight of updating all our pages on all our sites every time a new browser is released that supports this meta tag nonsense.

We've been summoned to fall into line for the benefit of Microsoft. And there's no corresponding benefit for the web, for the openness of standards, or for the future viability of the web.

There's no benefits to be seen here.

Backwards compatibility

Microsoft's commitment to backwards compatibility has compromised any ability to adopt modern open web standards. We web developers should not be paying for Microsoft's mistakes.

I was patient, and praised, the launch of Internet Explorer 7. I encouraged Chris Wilson and his team to keep up the sterling efforts.

In return I, as a web developer, have been directly blamed for Microsoft's failings. I'm expected to accept my new status as a second class web developer.

I believe this meta tag idea is Microsoft's last throw of the dice before finally admitting that Internet Explorer is dead in the water. Its clear the cost and complexity of development seriously outweigh the perceived value of adding in support for web standards.

It seems evident that if we, as web standards supporting web developers, stand up now and categorically reject Microsoft's proposal we stand a chance of effecting some badly needed change in Microsoft. They need to embrace open web standards unconditionally. They need to live up to their responsibilities as a browser vendor.

As to their demand of blind obedience: I don't think so. I have a better idea - end of line Internet Explorer.

End of line Internet Explorer

Cease all new development on Internet Explorer and put it in a permanent maintenance cycle. End of line it. That will ensure that all your clients continue to benefit from the backwards compatibility Microsoft is supposedly promising. You can leave that browser as part of the operating system.

If Microsoft is at all interested in supporting open web standards it should start a brand new project, with a brand new name, which will create a standards supporting browser from scratch. That browser can then be used to show Microsoft's true commitment to open standards.

This approach will neatly solve the conflict and avoid the compromising that has so plagued Internet Explorer 7 and 8. When the new browser project matures in four or five years, and when your clients have updated to modern, web standards compliant publishing tools, then gradually switch over your clients to the new browser.

An alternative proposal

I also have a second idea, which is perhaps more in keeping with the ethos of web standards. Its not a new idea, and credit goes to Shelley Powers for standing up and doing the right thing. I encourage all web developers who believe in web standards and what it means to be open to join me in this pledge.

Full spec support by 2010

I will no longer compensate for limited or broken specification support in browsers after January 1, 2010. This gives IE, and the other browsers, time to fully implement all of the specifications that have been out as recommendations for years now. This includes support for XHTML 1.1, CSS 2.1, SVG 1.1, in addition to any other specification not listed. This isn't part of a movement, and there is no badge. This is just my personal choice that I will no longer compensate for browsers not implementing standards, beginning January 1, 2010.

Its time to stand up for the web standards we hold dear. Its time to protect our web. Its time to say enough is enough. Its time for Microsoft to take responsibility for failing their clients over and over again. Its time for Microsoft to clean up its own mess.

I reject Microsoft's proposal. It undermines the spirit and the purpose of the World Wide Web.

Related links

Older Posts:

[ Weblog Frontpage | Blog categories and feeds | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]