Salakhetdinov Shamil
mcp2004 at mail.ru
Thu Feb 14 03:32:40 CST 2013
<<< Is this actually a critical issue for most people? Is it an issue that cannot be solved by either forking IE into two versions - IE and IE Classic? Or perhaps having a compatibility layer, like what already exists in IE, so that some things can use Trident if needed, while the main engine remains WebKit? >>> AFAIK Web Browser Automation is widely used. AFAIU (I can be wrong) Web Browser Automation "ties" could have been the source of IE's previous (before IE10) versions "slowness", "memory hungriness/leakages" etc. Still Microsoft could "kill" it as they did with VB6 and other technologies but as we can see with IE10 Microsoft have done a lot of work to fix the prev. IE versions issues. I doubt they would want to "throw away" all that work. And compatibility layer could result in Microsoft IE10 and new versions rendering/JavaScript interpretation code optimization results getting (partially) lost. I can be completely wrong. I do not know how IE code base is organized internally. -- Shamil Четверг, 14 февраля 2013, 1:04 -08:00 от Hans-Christian Andersen <hans.andersen at phulse.com>: > >> - because of the fact that IE and its rendering and Javascript interpretation engine(s) should be tightly coupled with Web Browser Automation and so it could be very hard to "cut/refactor that Automation ties" without breaking a lot of custom software using Web Browser Automation features. > >Is this actually a critical issue for most people? Is it an issue that cannot be solved by either forking IE into two versions - IE and IE Classic? Or perhaps having a compatibility layer, like what already exists in IE, so that some things can use Trident if needed, while the main engine remains WebKit? > >- Hans > > >On 2013-02-14, at 12:18 AM, Salakhetdinov Shamil < mcp2004 at mail.ru > wrote: > >> <<< >> As I have expressed previously here, I have my fingers crossed that Microsoft will follow suit. >>>>> >> I'd not mind :) ... but I doubt it will happen (real soon if ever): >> >> - first of all because as we all know "Microsoft is not following standards but they create them" :) and >> - because of the fact that IE and its rendering and Javascript interpretation engine(s) should be tightly coupled with Web Browser Automation and so it could be very hard to "cut/refactor that Automation ties" without breaking a lot of custom software using Web Browser Automation features. >> >> -- Shamil <<< skipped >>> >