22-04-08, 07:41 PM
Through the addition of a custom HTTP header or equivalent META element declaration, developers will be able to switch between different CSS and JavaScript engines.
The rationale for this move is understandable. With the release of IE7 in 2006, Microsoft made a huge leap towards bringing web standards support to its browser. However, this also resulted in many existing sites and intranet applications coded specifically to IE6 to break, resulting in complaints from developers, corporate customers and end users. With IE8, Microsoft has two contradictory aims: providing backwards compatibility, white also improving standards compliance. But many web standards proponents have been less than enthusiastic about the proposed solution.
We've been in a similar situation before. Today's web standards development was only made possible by the introduction of DOCTYPE switching m 2002, allowing for improved standards support while maintaining backwards-compatible quirks mode for legacy content. Mozilla introduced its own flavour of version switching in Firefox 1.5 and 2.0. However, in both cases the versioning was descriptive of the particular specification the pages and scripts were authored against, leaving it up to each browser to decide how to handle the content. IE8's proposed browser targeting moves back to the old 'this page best viewed in..: days.â€
In his article, Aaron suggested other browsers may want to adopt this form of version targeting. But judging by the responses from developers at Mozilla, Opera and Safari, this may well remain an IE-only solution, similar to conditional comments. Considering that X-UA-Compatible primarily solves a problem with IE-specific sites, the potential damage is at least contained.
The most polarising aspect of Microsoft's January announcement was the plan to have IE8 default to IE7 emulation, making improved standards-compliance an explicit opt-in — forcing developers to add the X-1.1A-Compatible incantation, or to adopt new DOCTYPEs like HTML5.
Microsoft's rationale of "don't break the web" seemed pragmatic and inevitable, but it sparked a heated debate among web standards. Perhaps it was this vocal opposition from developers, backed by Microsoft's newly drafted 'Interoperability Principles' and its focus on standards support, that led to an impressive reconsideration. Just as we thought the standards opt-in was a fait accompli, the IE team surprised everybody — including those WaSP members secretly involved in Microsoft's original proposal by announcing that IE8 would default to its most standards-compliant mode.
Web-standards-savvy developers should rejoice. No opt-in, no X-UA-Compatible ... if you code to standards, IE8 will render it accordingly. There will be bugs, as with every other browser, but the development methodology won't change: code to specifications, test in standards-compliant browsers, then add graceful degradation and DOM scripting capability checks where needed.
Developers who are still ignorant of web standards or somehow forced to code to specific versions of IE will be able to call time out and freeze the browser's rendering and behaviour to a particular version, without any `frantic scramble' to fix things for new versions. And, instead of having to block browser updates, corporate IT departments can set their servers to output the magic X-UA-Compatibte HTTP header, trigger IE7 emulation mode, and wait until their enterprise intranet applications are updated to work with IE8.
Browser version targeting may not be ideal from a purist's perspective, but at least standardistas now aren't forced to buy into it. Despite providing a get-out clause, the IE team does seem genuinely committed to standards. The beta version of 1E8 already shows dramatic improvements in layout (passing the ACID2 test and shooting for full CSS 2.1 compliance on release) and JavaScript. Thanks to the version targeting trade-off, Microsoft's new browser may see a wider adoption than IE7, allowing us to finally take advantage of up-to-date standards and features without the usual workarounds.
The rationale for this move is understandable. With the release of IE7 in 2006, Microsoft made a huge leap towards bringing web standards support to its browser. However, this also resulted in many existing sites and intranet applications coded specifically to IE6 to break, resulting in complaints from developers, corporate customers and end users. With IE8, Microsoft has two contradictory aims: providing backwards compatibility, white also improving standards compliance. But many web standards proponents have been less than enthusiastic about the proposed solution.
We've been in a similar situation before. Today's web standards development was only made possible by the introduction of DOCTYPE switching m 2002, allowing for improved standards support while maintaining backwards-compatible quirks mode for legacy content. Mozilla introduced its own flavour of version switching in Firefox 1.5 and 2.0. However, in both cases the versioning was descriptive of the particular specification the pages and scripts were authored against, leaving it up to each browser to decide how to handle the content. IE8's proposed browser targeting moves back to the old 'this page best viewed in..: days.â€
In his article, Aaron suggested other browsers may want to adopt this form of version targeting. But judging by the responses from developers at Mozilla, Opera and Safari, this may well remain an IE-only solution, similar to conditional comments. Considering that X-UA-Compatible primarily solves a problem with IE-specific sites, the potential damage is at least contained.
The most polarising aspect of Microsoft's January announcement was the plan to have IE8 default to IE7 emulation, making improved standards-compliance an explicit opt-in — forcing developers to add the X-1.1A-Compatible incantation, or to adopt new DOCTYPEs like HTML5.
Microsoft's rationale of "don't break the web" seemed pragmatic and inevitable, but it sparked a heated debate among web standards. Perhaps it was this vocal opposition from developers, backed by Microsoft's newly drafted 'Interoperability Principles' and its focus on standards support, that led to an impressive reconsideration. Just as we thought the standards opt-in was a fait accompli, the IE team surprised everybody — including those WaSP members secretly involved in Microsoft's original proposal by announcing that IE8 would default to its most standards-compliant mode.
Web-standards-savvy developers should rejoice. No opt-in, no X-UA-Compatible ... if you code to standards, IE8 will render it accordingly. There will be bugs, as with every other browser, but the development methodology won't change: code to specifications, test in standards-compliant browsers, then add graceful degradation and DOM scripting capability checks where needed.
Developers who are still ignorant of web standards or somehow forced to code to specific versions of IE will be able to call time out and freeze the browser's rendering and behaviour to a particular version, without any `frantic scramble' to fix things for new versions. And, instead of having to block browser updates, corporate IT departments can set their servers to output the magic X-UA-Compatibte HTTP header, trigger IE7 emulation mode, and wait until their enterprise intranet applications are updated to work with IE8.
Browser version targeting may not be ideal from a purist's perspective, but at least standardistas now aren't forced to buy into it. Despite providing a get-out clause, the IE team does seem genuinely committed to standards. The beta version of 1E8 already shows dramatic improvements in layout (passing the ACID2 test and shooting for full CSS 2.1 compliance on release) and JavaScript. Thanks to the version targeting trade-off, Microsoft's new browser may see a wider adoption than IE7, allowing us to finally take advantage of up-to-date standards and features without the usual workarounds.
Support
Webnetics UK Ltd.
Webnetics UK Ltd.