Interesting, but what I really, really want them to do is EOL IE 11 so that the web can move forward without feeling guilty about the X% of users still on it. IE 11 has unfortunately become the new IE 6.
As it is right now I believe the IE 11 EOL is tied to the Windows 10 EOL...which is not happening anytime soon. Many frameworks are dropping support for it anyway so I guess it will end up being defacto desupported.
As someone who has (luckily) only had to support Firefox/Edge/Chrome, can you go into why IE11 is so bad? In the very small amount of testing I've done, everything seems to render just fine (especially compared to IE6/7/8)
It's utterly depressing how many red "No"s there are in the left column next to green "Yes"s -- all the features we could use if we could merely drop support for IE11.
I've been on multi year projects to modernize old IE applications, and one of the things that IE11 misses is "standard" xpath evaluation. A lot of old "dhtml" apps were all in on soap/xml. There's some wierd IE only hold over css in it like cursor hand vs pointer. On the whole it's not too bad really.
The reason why IE11 will live for a long, long time is it's compatability modes. You can run apps all the way back to IE7 on it. And yes these still exist.
>There's some wierd IE only hold over css in it like cursor hand vs pointer
Wow, that would really frustrate me. One of the first things I do (or check to make sure it's done by whatever css library I'm using) is add
a {
cursor:pointer;
}
to my css file. The first time I tested a website in IE11, I would be pulling my hair out!! Or more likely I would google it, but still, it would be frustrating.
IE 11 is the last browser with any substantial share that is no longer being actively developed (and automatically updated). As such the are a number of new features that get broad support in "evergreen" browsers that IE will never support. Most frameworks and developers end up bending over backwards to polyfill these features leading to more complex code and larger file sizes. Here are a few examples:
Every other major browser supports this natively aside from IE, but most people still transpile their modern code down to ES5 + polyfills for compatibility
Again, widely supported, but instead we use tools like SASS/LESS
Web Components[1] (Shadow DOM[2] and Custom Elements[3])
Newer frameworks like Ionic 4 rely heavily and web components and see it as the future of all UI frameworks and the end of framework churn[4]. Once again IE 11 holds back the pack and has to be pollyfilled[5]
Vuejs is completely rewriting its observation mechanism[6] to be proxy-based in version 3, however it appears that cannot be polyfilled and so they will be providing a second, optional, not-fully-compatible build, specifically for IE 11[7]
> Most of the ES2015 features used can be transpiled / polyfilled for IE11, with the exception for Proxies. Our plan is to implement an alternative observer with the same API, but using the good old ES5 Object.defineProperty API. A separate build of Vue 3.x will be distributed using this observer implementation. However, this build will be subject to the same change detection caveats of Vue 2.x and thus not fully compatible with the “modern” build of 3.x. We are aware that this imposes some inconvenience for library authors as they will need to be aware of compatibility for two different builds
SharePoint Online’s user interface has been rewritten in recent years using an open source stack (node.js, React etc) and certainly works far better using Chrome and not IE. This is true of SharePoint on-prem too, at least the recent versions. Even the tools we use to make web parts now are React, Yeoman, webpack, Yarn, Sass etc. Microsoft are heavily investing in these and most of the training materials they produce for developers are pushing us more and more in that direction.
In my understanding, Corporate is tied to IE for three reasons: it is easy to manage via central policies, it is reliable at rendering legacy (esp. intranet) apps, and Edge isn't even available for some Windows editions (Enterprise LTSB).
Especially the second point isn't new. So in the past, MS has built compatibility modes into IE, where a modern rendering engine is used by default (or at least when a certain X-UA-Compatible header/meta tag is present) and a fallback engine is used upon certain triggers (explicitly via compatibility lists and X-UA-Compatible, or via heuristics, e.g. for intranet sites).
I don't understand why they couldn't do a similar thing now: use EdgeHTML in IE by default, and fall back to Trident via certain triggers.
Yes, it would have required using two different rendering engines, while IE 10 and earlier can be emulated by IE 11 Trident. I don't know how IE is built, but heck, in the early Firefox days, I used to have an extension that could seamlessly switch to IE rendering within the Firefox window. So I would like to believe that a better solution than making IE the new Walking Dead among browsers should be realistic for MS.
What really pains me is the X% of users still on Safari 9. Not only does it not support a lot of new features, but how do you even test it? At least IE11 I can easily spin up a free VM to test.
As it is right now I believe the IE 11 EOL is tied to the Windows 10 EOL...which is not happening anytime soon. Many frameworks are dropping support for it anyway so I guess it will end up being defacto desupported.