soumya
In the zone
IE8 is the last version of the Internet Explorer Web browser. At least, that's what I'm hearing through the grapevine. It seems that Microsoft is preparing to throw in the towel on its Internet Explorer engine once and for all.
And just what will be its replacement? I’m getting conflicting stories on that one. Some are still claiming that Microsoft will go with WebKit, which, thanks to the popularity of Apple's Safari browser and also Google's Chrome, is rapidly becoming a de facto standard for all non-IE and non-Firefox implementations.
Others insist that that the whole WebKit story is merely a feint and that Microsoft will in fact be adopting a brand-new engine coming out of its Microsoft Research division. Dubbed "Gazelle," this new engine will supposedly be more secure than Firefox or even Chrome, making copious use of sandboxing to keep its myriad plug-ins isolated and the overall browser process model protected.
But regardless of which direction Microsoft takes -- WebKit or Gazelle -- it will still have to navigate the treacherous waters of legacy ActiveX support. And as someone who has spent some not-so-quality time developing ActiveX controls in the past, the need to maintain some sort of compatibility layer within any proposed IE replacement is a critical consideration.
For most casual users (i.e., grandma in her den surfing eBay), ActiveX was and is just another annoying RIA (rich Internet application) mechanism, one that has increasingly been supplanted by Adobe Flash or various AJAX-based mechanisms. However, for enterprise IT shops with a heavy Microsoft investment, ActiveX has long been an integral part of many in-house applications.
If Microsoft intends to pull the plug on IE after version 8, it will need to articulate a clear legacy migration strategy that allows these shops to preserve their investments in ActiveX controls and resources.
Then there’s the issue of legacy HTML/CSS support. So much of the Web has been tweaked for IE 6.x compatibility that even Microsoft's own attempts to implement a more standards-compliant browser engine in IE8 have met with disastrous results. For me, the situation so bad that when I do find myself using IE 8 (typically, to view a site that causes my copy of the Chrome 2.x beta release to blow up), I end up configuring IE 8's compatibility mode as the default viewing option since the browser's native rendering mode breaks practically every site I visit.
Finally, there's the matter of third-party developers using IE's rendering engine with their own applications. A good example would be a program that includes a help file in HTML format and then uses a custom form to display an embedded Web browser object to host the file. This embedded object is invariably an ActiveX container for the IE engine that's installed with Windows, so any attempt to remove IE from the OS -- or to radically change its core underpinnings -- will need to account for applications that rely on the existence of an accessible, programmable IE object model.
Of course, all of the above is old hat for Microsoft, a company whose status as global software leader too often makes it a victim of its own success. I, for one, look forward to the possibility of a clean break with IE's creaky old rendering engine. But I hope the company pays more care and attention to preserving legacy compatibility than it did with some of its more recent OS efforts.
Source
And just what will be its replacement? I’m getting conflicting stories on that one. Some are still claiming that Microsoft will go with WebKit, which, thanks to the popularity of Apple's Safari browser and also Google's Chrome, is rapidly becoming a de facto standard for all non-IE and non-Firefox implementations.
Others insist that that the whole WebKit story is merely a feint and that Microsoft will in fact be adopting a brand-new engine coming out of its Microsoft Research division. Dubbed "Gazelle," this new engine will supposedly be more secure than Firefox or even Chrome, making copious use of sandboxing to keep its myriad plug-ins isolated and the overall browser process model protected.
But regardless of which direction Microsoft takes -- WebKit or Gazelle -- it will still have to navigate the treacherous waters of legacy ActiveX support. And as someone who has spent some not-so-quality time developing ActiveX controls in the past, the need to maintain some sort of compatibility layer within any proposed IE replacement is a critical consideration.
For most casual users (i.e., grandma in her den surfing eBay), ActiveX was and is just another annoying RIA (rich Internet application) mechanism, one that has increasingly been supplanted by Adobe Flash or various AJAX-based mechanisms. However, for enterprise IT shops with a heavy Microsoft investment, ActiveX has long been an integral part of many in-house applications.
If Microsoft intends to pull the plug on IE after version 8, it will need to articulate a clear legacy migration strategy that allows these shops to preserve their investments in ActiveX controls and resources.
Then there’s the issue of legacy HTML/CSS support. So much of the Web has been tweaked for IE 6.x compatibility that even Microsoft's own attempts to implement a more standards-compliant browser engine in IE8 have met with disastrous results. For me, the situation so bad that when I do find myself using IE 8 (typically, to view a site that causes my copy of the Chrome 2.x beta release to blow up), I end up configuring IE 8's compatibility mode as the default viewing option since the browser's native rendering mode breaks practically every site I visit.
Finally, there's the matter of third-party developers using IE's rendering engine with their own applications. A good example would be a program that includes a help file in HTML format and then uses a custom form to display an embedded Web browser object to host the file. This embedded object is invariably an ActiveX container for the IE engine that's installed with Windows, so any attempt to remove IE from the OS -- or to radically change its core underpinnings -- will need to account for applications that rely on the existence of an accessible, programmable IE object model.
Of course, all of the above is old hat for Microsoft, a company whose status as global software leader too often makes it a victim of its own success. I, for one, look forward to the possibility of a clean break with IE's creaky old rendering engine. But I hope the company pays more care and attention to preserving legacy compatibility than it did with some of its more recent OS efforts.
Source
