IE's "opt-in" nightmare comes true
So basically what this all means is that MS will 'lock down' their implementation of existing standards with each new release of Internet Explorer, bugs quirks and shortcomings included. Than everyone has to wait a year or two, three, four, five until the next version of IE comes along that fixes things. By then most less-knowledgable webdevelopers have come to rely on IE's quirks and produced a whole generation of websites that won't play nice with the new version of IE so the "opt-in" switch can never be altered again and support for this rendermode has to be maintained, indefinitely.
How should other browservendors go about this? Should they add support for these switches as well? Reverse-engineer IE's implementation with each release and have their codebase grow both in size and complexity? Is that where we're going? MS once again dictating the current state of the web with their sub-optimal buggy implementions of existing standards? Have them give it their own flavour for each version of IE to come in order to gain competitive advantage (at the cost of interoperability) for as long as they still have a dominant position in the browser-market? Well, at least I must admit that their ugly intentions are clearly visible to all of us (or at least to me )...
I do see a small glimpse of hope though; Chris Wilson responded to a question:
I sincerely hope he means that a new doctype, like HTML5's, will *always* opt-in to the "latest standards compliant mode" in each coming version of IE. In fact I strongly encourage the HTML5 WG to add something in the line of "UA's must not intentionally restrict or alter HTML5 content rendering based upon proprietary versioning flags but must always follow the UA requirements to the extend of the capabilities of their rendering-engine" as a UA-requirement for compliance.# re: Compatibility and IE8
Tuesday, January 22, 2008 12:03 PM by cwilso
@SvenGroot, @David Zülke: of course, for content that we don't have backward compatibility concerns for (a new DOCTYPE or MIME type, e.g.), we can automatically opt in.
Then there's one thing that also caught my attention in the ALA-article (by the new MS marionette Aaron Gustafon):
Since when can a META http-equiv-element take precedence over the same HTTP-header? Are UA's that want/have to support this feature really required to *always* sniff for this silly tag regardless of what the headers dictate? Not only do I call this abuse of the meta-element, I call it backwards or a poor choice at least. And where exactly can implementors find the exact specification and behaviour for this specific META-tag or will that remain MS-proprietary as well?We can also use both methods in concert. For example, it is possible to set a baseline lock on a whole site using the header method and then override that header on individual pages, as needed, using the meta element.
But I guess that was the last thing I was dreaming about. It's just unbelievable.
Microsoft uses opt-in to encourage (lazy) developers to code for a specific version of IE. This will assure Microsoft of future market share: it forces users (both consumers and companies) to stick with IE in general, because their crappy [CRM|ERP|CMS|Intranet] is built on the quirks of a particular IE version.
The automatic "opt-in" for HTML5 documents might save the web from this big disaster.
Comments are closed