Weblogs: Web Standards

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:

• Does the end result for web standards developers differ?
• Does it solve the issue from Microsoft's standpoint?

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.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]