Compatibility with IE11 (Internet Explorer 11)

[maxbarnas]

Long story short – CKEditor 5 doesn't work on IE11. Making it compatible with IE11 is a complex and long task – read more about the status of things and how you can help.

[maxbarnas]

Unit tests: 2258 are passing.

Most of failed tests are actually broken. Those not broken have most of the time the error:

TypeError: Unable to get property 'get' of undefined or null reference.

I wasn't spending more time trying to find the source of such error, but that would be my starting point.

Manual tests: Not a single manual test could be passed.

Every time I get Deferment unlock timeout - "2" never unlocked. error from Bender.

[Reinmar]

Super, thanks. It's usually a good news if many failed tests share the same error :D.

[djanosik]

There is a problem either in transpiler or in polyfill related to Symbol which causes this condition to be always true. The attributes property will never get initialized and the TypeError is thrown. When I fix this, the editor starts to crash (or hang) in IE11.

[Reinmar]

Interesting... this doesn't seem to be some tricky scenario so it's odd that Babel fails on that. How did you change it so it worked? observable[ attributeSymbol ]?

[Reinmar]

Nah, observable[ attributeSymbol ] would be unsafe. observable.hasOwnProperty( attributeSymbol )?

[djanosik]

@Reinmar Yes, hasOwnProperty works quite well.

[Reinmar]

So, I guess the next step would be to run ckeditor5-utils tests and then ckeditor5-engine. That may give some idea what's crashing. But since this requires transpiling the code we'd need support for that in https://github.com/ckeditor/ckeditor5-dev/blob/master/packages/ckeditor5-dev-tests/lib/utils/automated-tests/getwebpackconfig.js (we could add it under --es5 flag... I even think we supported it at some stage :D)

[djanosik]

Some other issues:

• Error on document.createTreeWalker missing some args.
• Crashes and hangs on container.remove(), because remove() function doesn't exist and is being called many (like hundred) times. There is probably some issue with callbacks.
• Selection.extend(...) is missing. When I comment out this line it starts to work, but selection is not reliable.

[Reinmar]

Yeah, good old browsers :|.

I think that before we'll start fixing these issue we need to figure out how to do that without bloating the existing code. By the issues you found it seems that we need more polyfills for missing/outdated methods. I wonder if we can safely polyfill all these.

[djanosik]

Any chance first release of CKE5 will work in IE11?

[Reinmar]

It depends. We don't know how far we are from making CKE5 really work in IE11. We'll check that after releasing 1.0.0 alpha and see if we'll be able to bring IE11 support for 1.0.0 final.

[djanosik]

Ok, thanks. Our decision whether to use CKE5 depends on it. Unfortunately we have many customers who are still using IE11 :/

[wwalc]

~~I did a quick search and it looks like IE11 will be supported by MS for some good time still (as long as Win 10 is supported): https://support.microsoft.com/en-us/help/17454/lifecycle-faq-internet-explorer ... which means at least until the end of 2020 (?) https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet~~

[lindenthal]

Dear CK 5 team,

first of all thanks a lot for putting so much effort into this editor. Here at OpenProject we just did a spike with it. The development of custom plugins is so much easier when compared with other editors. So my congratulations to your design decisions. Your editor is really awesome!

Getting back to the IE 11 topic:

Here at OpenProject we had a very similar discussion 2 years ago. We decided to drop support for IE 11. We had to make a decision whether we want to invest our time into the future or in the past. And we decided to invest into the future. Looking back I think it was the right decision. The browser landscape has changed dramatically in the last two years. We work for a large number of large corporates and governmental organizations. All of them are allowed to use modern browsers now. So if you ask them: Do we need to support IE 11 they all say Yes. If you ask them Are you allowed to use modern browsers they als say Yes. And if you ask them Do you want new features they also say Yes. And if you ask them Are you willing to pay the effort required to support IE 11 they say No.

These people are slowing down the entire innovation by sticking to their legacy world. If application developers continue to support IE11 this will give them less pressure to move on.

In my opinion more people would benefit from features such as table-support. Or legal requirements such as full accessibility.

@wwalc and @Reinmar and @djanosik: wouldn't it be an option to provide (paid) long-term support for CK4 until the end of IE11 min 2020? And everybody who wants the new features of CK5 needs modern browsers?

Again: Thanks a lot for all the hard work you for the community. I really appreciate that.

[djanosik]

@lindenthal I guess it would be ok to use CKE4. But how do I create headless CKE4 editor? CKE5 is modular and replacing UI with our own is quite easy.

• Do we need to support IE11? Yes :/
• Are you allowed to use modern browsers? Yes, mostly. But our solutions are also integrated into legacy systems that don't work in modern browsers. Also don't forget IE11 is usually the only option available on Windows Servers. There is no Edge and admins don't allow to install 3rd party apps.
• Do you want new features? Of course. But I think we can find a compromise here. We need CKE5 to not crash in IE11 and to support at least some basic editing features. I can explain why some features are not available. But I can't explain why it doesn't work at all.
• Are you willing to pay the effort required to support IE11? Not sure here.

[lindenthal]

Hi @djanosik,

I do understand your concerns but please allow me to exaggerate a little so you can better understand my position.

Actually you just confirmed my thesis: The development of modern web application is slown down by poorly maintained legacy applications. So people like the CKE developers, you and I have to suffer from that. And as I said: These companies that built up this technical debt try to hand over their problem to others. Which actually means that these companies are asking other open source developers to pay for their technical debt.

But I guess there are many other opinions on that :-)

Best Niels

[caffodian]

I work in a field where IE11 is unfortunately still required, and customers can't easily upgrade. (Hospitals and other health) I haven't looked very much into what is actually broken with CKE5 under IE11, but I've had to deal with similar problems with polyfilling for IE11 in the past.

There are a few conditionals, but supporting IE11 (through webpack magic) would probably be something I'd be willing to pay for, or to help look into and work on.

[lindenthal]

@caffodian

I suggest you first upgrade to modern browsers and then upgrade to CK5. What is wrong with that approach? I have never heard anybody who said they can not use a modern Edge, Chrome or FF because of stability or security concerns. Do you?

[ckotzbauer]

@lindenthal Yes, I have. Our software is used from bigger companies. I've tried to stop IE support, but they said it's the default browser. There are many computers which do not run with Win 10 yet, so no Edge is available. And other browsers are not really wanted... I'm glad that we ONLY have to support IE11 and not older ones. IE century isn't over (especially for companies)

[lindenthal]

@code-chris

I guess you agree that FF and Chrome both work perfectly fine on Windows 7, right? And even if the IE11 is the default browser in an organiatzion this does not imply that they can not use FF in parallel. And for the very small fraction that can not install FF, they should simply stick to CK4.

The only reason to chose IE11 over FF are poorly maintained legacy web applications. I am not aware of any other reason.

The point is: The more applications continue to support IE 11 the longer it will take to get rid of it. So by supporting IE 11 we make this problem even worse.

You know there is another group of people that makes me even more angry: The people that request to support the combination of legacy browser with legacy screen readers (IE11 with JAWS 15). This combination really kills any UX and innovation. Did you ever see some of these people paying for the additional effort they create?

[ckotzbauer]

@lindenthal I agree with you. No problem. I would like to kill IE immediately too. But unfortunately it's hard to stop IE support in commercially used software. And yes, as longer IE is supported from components like this one, as longer it will take until this browser dies completely.

The reason why I hope that CK5 will support IE is not cause of the browser:

• Our main product uses now a self-written Editor component which is really worse. I want to replace it with CK. But if I replace it with CK4, then I finally have duplicate effort (Self-Written to CK4 and later to CK5)
• CK4 does not support Webpack or has any other compatible solution.

[hubertguillemain]

Until the argument wether IE 11 shall or shall not be officially supported is closed, has anyone come up with a workaround solution using external polyfill libraries?

[Infuser]

I think anyone thinking IE11 support is not vital is not being realistic, I work for a large company that makes software for our customers a large number of them want IE11 support, I wish they didn’t but they do.

Currently I am developing a completely new front end in which I would like to use ckeditor5 but I cannot because of no IE11 support. Additionally it sounds like the upgrade path from ckeditor4 to 5 is difficult and we will have issues converting our customers old data. This means not only do we have to use ckeditor4 but we will be stuck on ckeditor4 forever.

[Reinmar]

To make it clear – while none of us personally want to work on adding support for IE11 (which feeling, I can see, you understand), it’s basically a matter of funding and opportunities for the project. You can always contact us (https://cksource.com/contact/) to discuss the options.

---

I've missed this question previously:

@wwalc and @Reinmar and @djanosik: wouldn't it be an option to provide (paid) long-term support for CK4 until the end of IE11 min 2020? And everybody who wants the new features of CK5 needs modern browsers?

The answer can be found in our Help center – "How long will CKEditor 4 be supported?

CKEditor 4 is a stable and mature application, which had its initial release at the end of 2012 and has been actively developed and improved since then. The CKEditor 4.x line is under a “Long Term Support” (LTS) programme which means that its development and support is guaranteed until 2023. If you are looking for a proven solution that will be fully supported for years, CKEditor 4 is a perfect choice.

[Reinmar]

@long-lazuli asked a few questions how to start investigating IE11 support:

I saw that main problems are es6-class & es6 getter/setter so I thought it can be possible to compile it with some babel plugins.

Please take a look at https://docs.ckeditor.com/ckeditor5/latest/builds/guides/integration/advanced-setup.html#option-building-to-es5-target. I hope it will help.

then I start digging in babel-plugins compiling to see if I can make things work on old projects. the best I can imagine is to build a polyfill file dedicated to this browser.

It depends and, TBH, it's hard to tell without digging. The first thing to do will be to:

1. Make sure that you build CKEditor 5 to ES5, so there are no syntactic errors.
2. Make sure you load polyfills for ES's globals such as Map/Set/WeakMap/WeakSet/Symbol.
3. Check out missing HTML globals and features. Here, it becomes slippery. Sometimes you may try to load some well-known polyfills. E.g. Node#remove() may require one. But some HTML features that we rely on may not have proper polyfills. It requires a lot of testing basically. @djanosik already did some research in https://github.com/ckeditor/ckeditor5/issues/330#issuecomment-311895564.
4. Finally, there are browser bugs, "incomplete implementations" and "it works like this cause why not; ouch, and this time it worked differently cause it can!". In the world of contentEditable that's pretty broken even today. In IE11 you'll have to chase issues one by one and in case of them polyfills won't help. You may need to propose PRs for them with if ( iAmIE ) { doWeirdStuff() } else { doNormalStuff() } pieces.

The first two steps are provided by Babel polyfills. Then, there's a matter of finding or writing polyfills for HTML features we rely on or finding workarounds to not need them at all (will require PRs). Then, it'll get even darker and more smelly and you'll be chasing bugs and quirks of which it's plenty in IE11. At this stage, though, the editor should be quite usable already.

Anyway... good luck :)

PS. The best way to share your work and findings will be:

1. To fork https://github.com/ckeditor/ckeditor5 and one of the builds repo.
2. Modify ckeditor5/mgit.json to use your build's fork.
3. Modify that build's webpack.config.js and whatever else you'll need to load all the polyfills and stuff required by steps 1-3.

Thanks to that, the next person, or we, will be able to jump in and help.

You can read more about out development env in https://docs.ckeditor.com/ckeditor5/latest/framework/guides/contributing/development-environment.html

[tuespetre]

I've got something together that seems to be working so far. Everything I've run into so far could be handled with some polyfills, save for one thing: the CSS custom properties. I had to do horrible things in a webpack.config.js file to make that work out nicely.

How can I wire this up to the test harness though? I have made a separate local repo called ckeditor5-build-ie11. It is a sibling folder to the ckeditor5 repo where mgit and lerna et al are used. I have been tweaking the files under the packages folder so that my changes will be easy to enumerate (even though they will ultimately be undone as I put together a single IE11 polyfill file.)

[brianteeman]

Great news

[Reinmar]

I've got something together that seems to be working so far.

🎉 awesome :)

I have made a separate local repo called ckeditor5-build-ie11

I think that you just need to commit and push changes in that repo and all other touched repos. In all cases – you need to do that to your forks of those repos. Plus, you would have to change mgit.json so it points out to your forks. Like this:

"@ckeditor/ckeditor5-engine": "tuespetre/ckeditor5-engine#branch-name",

(you can omit #branch-name if you were committing straight to master)

Regarding some webpack configs and a sample – you can place those in the main repo (the fork of ckeditor5). From that repository, you can import all other pkgs, some polyfills (if you'll install them), etc.

[tuespetre]

I'm currently fighting some caret weirdness so I'm learning more about Selection/MutationObserver/contenteditable implementation differences to try and nail it down. I'm mostly comparing between IE11, Edge, and Chrome. I'm seeing some bits of the weirdness surface in Edge so maybe some more good can come out of this endeavor besides just supporting an antiquated browser :trollface:

[Reinmar]

I'm seeing some bits of the weirdness surface in Edge so maybe some more good can come out of this endeavor besides just supporting an antiquated browser

I can feel your pain :D Edge is causing us some headaches – personally, I've got a feeling that it's even less stable than old IE versions ;/. One tip – the F12 dev tools change the bahaviour of the browser, so we try to remember to debug things with the console closed (sic!)

Anyway, 🤞

If you'll find some interesting Edge bugs (and or workarounds) let us know – it sometimes help to 👍 on the MS's issue tracker.

[tuespetre]

I’ve submitted a PR to the engine repository that addresses the thing I was seeing in Edge (and Firefox!) but it will need a little feedback because I’m not sure how to handle the existing test cases surrounding it.

One IE11-only issue I have found is that upon the user focusing an editing host via a click, selectionchange fires twice: once to place the caret at position 0, and again to place the caret where the user actually intended for it to be by clicking. Meanwhile, upon programmatic focus, it sets the position to 0 (say, after inserting a link and the plugin gives focus back to the editor.) If I can find a good mechanism for detecting ‘click focus’ versus ‘programmatic focus’ I should be able to do something there.

The only other one I am seeing yet is a tough one because it needs me to study the workings of the engine itself to figure out. It’s related to MutationObserver and the two-step caret binding. I’m seeing cases where whitespace cannot be inserted at the end of a highlighted link, or it is inserted and then ‘breaks off’ when other text is typed, or an IndexSizeError is thrown when _updateDomSelection tries to modify the selection (due to the DOM text node being shorter than expected as in the model’s text node, for some reason.)

I’ll keep trying to hash these out as separate things to make it easier to integrate them, but I will try and push the ckeditor5-build-ie11 up before then so maybe others can at least check it out.

[Reinmar]

I've seen and replied to your PR (https://github.com/ckeditor/ckeditor5-engine/pull/1442). We still need some work there, but it's promising :)

Meanwhile, upon programmatic focus, it sets the position to 0 (say, after inserting a link and the plugin gives focus back to the editor.)

I remember there were significant differences between how IE and normal browsers handle selection in editable hosts which lost focus. You'd need to change this scenario behaves in various browsers:

1. Make some selection inside a native contentEditable element.
2. Click outside.
3. Focus it via some non-intrusive way (e.g. setting a setTimeout() earlier; don't use the console as it affects the focus and selection).

Will other browsers restore the previous selection? Or will all browsers set the new selection (on focus) on position 0?

If all do the latter, we'd have a bug everywhere (unless focus is fired asynchronously). That's because we do this in editor.editing.view.render():

    focus() {
        if ( !this.document.isFocused ) {
            const editable = this.document.selection.editableElement;

            if ( editable ) {
                this.domConverter.focus( editable );
                this.render();
            } else {
                /**
                 * Before focusing view document, selection should be placed inside one of the view's editables.
                 * Normally its selection will be converted from model document (which have default selection), but
                 * when using view document on its own, we need to manually place selection before focusing it.
                 *
                 * @error view-focus-no-selection
                 */
                log.warn( 'view-focus-no-selection: There is no selection in any editable to focus.' );
            }
        }
    }

We first focus the editable element and then, synchronously, render the current view. I don't remember now how it works – does render() restore the previous selection because domConverter.focus() caused asynchronous focus so when render() is called we still have the old selection in the model/view? Or are modern browsers restoring the selection by themselves so the fired focus event doesn't reset the last stored selection?

Anyway, what I can tell now is that IEs always had problems with the fact that there could be just one selection in the entire window. So, once you took the focus out of the editable, the selection was irreversibly lost there. In the past, in CKEditor 3, we used iframes (so we have multiple windows) and modals (which have focusable input fields) were placed in the main window while the editable was places in an inner window. Then, when we introduced inline editables (in CKEditor 4), we had to introduce selection locking and restoring to handle selection preservation when moving focus to focusable elements in the UI. I don't know now, though, whether this was needed still only for IE or for all browsers. In CKEditor 5 we don't have a selection restoring system yet and everything worked really fine for now. So, how's IE11 different here?

[Reinmar]

The only other one I am seeing yet is a tough one because it needs me to study the workings of the engine itself to figure out. It’s related to MutationObserver and the two-step caret binding. I’m seeing cases where whitespace cannot be inserted at the end of a highlighted link, or it is inserted and then ‘breaks off’ when other text is typed, or an IndexSizeError is thrown when _updateDomSelection tries to modify the selection (due to the DOM text node being shorter than expected as in the model’s text node, for some reason.)

I'd recommend progressive enhancement – does disabling the two-step caret movement help? If so, let's forget about it in IE11 ;) If not, we'll need to talk about input handling, which is something I wouldn't like to start :D

[tuespetre]

I figured out the IndexSizeError problem in IE for inserting whitespace at the end of a link. IE has a peculiar behavior with setting the href attribute (either via the property or via setAttribute) of an <a> that is contained within a connected editing host -- it updates the textContent to match the value being set for href if the href and the textContent pointed at the same URI. This wreaked havoc for the rendering system. Fortunately it's something I was able to feature test for and shim in the IE11 polyfills file.

(function() {
    var host = document.createElement('div');
    host.contentEditable = true;
    host.style.display = 'none';
    var link = document.createElement('a');
    link.textContent = 'https://example.org';
    link.href = 'https://example.org';
    host.appendChild(link);
    document.documentElement.appendChild(host);
    link.href = 'https://example.org?';
    if (link.textContent === 'https://example.org?') {    
        var oldHrefDescriptor = Object.getOwnPropertyDescriptor(HTMLAnchorElement.prototype, 'href');
        Object.defineProperty(HTMLAnchorElement.prototype, 'href', {
            get: oldHrefDescriptor.get,
            set: function(value) {
                var hasElements = false;
                for (var i = 0; i < this.childNodes.length; i++) {
                    if (this.childNodes[i] instanceof Element) {
                        oldHrefDescriptor.set.call(this, value);
                        return;
                    }
                }                
                var oldText = this.textContent;
                oldHrefDescriptor.set.call(this, value);
                if (this.textContent !== oldText) {
                    this.textContent = oldText;
                }
            }
        });
        var oldSetAttribute = Element.prototype.setAttribute;
        Object.defineProperty(HTMLAnchorElement.prototype, 'setAttribute', {
            value: function(key, value) {
                if (key.toLowerCase().trim() === 'href') {
                    this.href = value;
                }
                else {
                    oldSetAttribute.call(this, key, value);
                }
            }
        });
    }
    document.documentElement.removeChild(host);
})();

[tuespetre]

Will other browsers restore the previous selection? Or will all browsers set the new selection (on focus) on position 0?

No browser seems to recall the previous selection; the problem really was that IE fires selectionchange before focus. Firefox also does this, but only in some very specific circumstances (I have filed a bug report for them here: https://bugzilla.mozilla.org/show_bug.cgi?id=1470876) This seems to have been largely addressed by decoupling selection/focus.

we'll need to talk about input handling, which is something I wouldn't like to start :D

I'm already started 😛

First things first, within _processDataFromDomText, _checkShouldLeftTrimDomText and _checkShouldRightTrimDomText prove to be problematic in instances where the browser wants to put out a childList MutationRecord to insert a single Text node consisting of \x20. I'm wondering if this should be a special case -- something like if the node is a single \x20 space, and there is either a prevNode or nextNode, return the \x20 as-is.

[tuespetre]

So the issue I've seen in Edge is that when you key in a space in the middle of a bunch of spaces, it fires extraneous events -- first a mutation observer callback with a characterData record at which point the selection has not changed at all (unlike FF, Chrome, and IE, where the selection has changed to be the position after the newly inserted character), then another mutation observer callback with two records (added and removed nodes) at which point the selection has changed to be the position after the first space in the sequence of spaces (what the hell?), then finally it fires input (totally backwards, that should come before the mutation records) and selectionchange, and during both of those events the selection has changed to be after the newly inserted character. But the way the CKEditor engine is responding to these events, it's forcing Edge to keep the caret at the point of insertion, which causes subsequent spaces to be in 'insertion mode'.

After carefully recording events and mutations among the different browsers, it's looking like it's going to be near-impossible to get it all right without... input handling 🎉

The only truly reliable input events I'm seeing are keydown and keyup as a pair, or compositionstart and compositionend as a pair -- the browsers handle keydown and keyup along with beforeinput, input, and selectionchange very differently during composition.

[rajeshs21]

Can you please confirm ckeditor 5 is compatible with IE 11?

[Jetski5822]

Hey guys, any idea when this will be ready?

[Suraj151]

i able to transform compiled ckeditor.js (es6) to es5 with babel plugins to support IE11 but now Symbol feature give me object error like TypeError: Unable to get property 'get' of undefined or null reference. for the all Symbols defined in packages. any help to solve it as i want it immediately to integrate this editor in our site as soon as possible

[AntonMedviediev]

Hello Guys, does anyone from you gain worked ES5 version of the ckeditor or this is a trip without end? I'm ashamed of me, but I really need to make this stuff works on ie11.

As I understand from all of your messages it`s really tricky task. I hope that someone from you will answer how far he went.

Personally, I want to try rewrite it to TS and put ES5 compilation to the awesome-ts-loader, I think it should be simplier than fight with babel, polyfills and so on and so far )

Hope on your wise advices :)

[tuespetre]

Getting it to go to ES5 was just a matter of hunting down a couple/few oddities. Then there was getting the build with CSS going.

Once you’ve got that done though, you still have left the cross-browser issues with the event/selection model. That’s too much work to get right alone, I’m afraid.

[vitality82]

Must agree with all about IE, but having clients using IE11 is a deal breaker. Reverting back to v4.

[duracell80]

It could be justification for dropping IE11 at least for users that create content. As long as the editor produced code that still worked in IE11, there could be a graceful transition across apps that are stuck with CK Editor. With different classes of users being advised as to what their limits are with IE.

What is the status of support, given that this has been ongoing for 2 years?

[Reinmar]

Bringing any level of compatibility with IE11 is a problem not only because of the time that is required for it initially, but also later for maintenance. IE11, despite being a huge improvement over e.g. IE9, is still significantly different than Edge (which, in turn, is quite different than other browsers). The lack of ES5 support is the most trivial problem here. The lack of certain modern APIs is also not the hardest part. What takes the most time and requires often times requires reverse-engineering the browser is understanding those "little" quirks of IE11, which make your app crash or look completely buggy.

We can either spend several months on trying to support this browser... or bring many interesting features such as autocompleting (mentions), placeholders, RTL support, make further tables enhancement, solve some content compatibility issues to support content created with other editors that allowed for much more freedom (which is in fact a huge issue), improve the documentation and write tutorials. Lots of things can be done within the time required to fix IE11. Seeing that it's market share is dropping, and some companies drop support for this browser earlier than Microsoft, it's really a hard pick.

I'm not trying to write that we will not work on it, just trying to clarify why not much has been happening here so far. For example we've been working recently on Angular, React, Vue integrations, Paste from Office support (coming in the next release). All that would also not appear if we focused on IE11.

What could possibly help to speed this up is if we get contacted by companies willing to participate in sponsoring this feature, or at least interested in getting a commercial license for CKEditor, if IE11 will be fixed, in such case we may try to scale and designate people onto it much sooner.

[Reinmar]

BTW, I rechecked how long IE11 will be supported.

https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support

Beginning January 12, 2016, only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates. Internet Explorer 11 is the last version of Internet Explorer, and will continue to receive security updates, compatibility fixes, and technical support on Windows 7, Windows 8.1, and Windows 10.

According to https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

the end of support for Windows 10 looks like a million years from now (2028 and increasing):

Random URLs about the topic:

• https://medium.com/@burger.neal/the-end-of-life-of-internet-explorer-11-12736f9ff75f
• https://www.quora.com/When-will-Microsoft-stop-supporting-IE-11-I-cant-find-anything-via-Google

[brianteeman]

and sadly that is why ie11 support is requested.

personally speaking I am happy if there is a definitive statement saying "no there won't be an ie11 version" rather than hanging in limbo

[Reinmar]

personally speaking I am happy if there is a definitive statement saying "no there won't be an ie11 version" rather than hanging in limbo

We successfully cooperated with many companies in the past which resulted in delivering many features that might not have been developed otherwise, so I can't say – "it won't be done". It's an open topic. But I understand that a definitive answer would make it easier for you to make a decision :) I'm sorry for not being able to give it.

[duracell80]

For enterprise users I can see them sticking with IE11 over Edge for many years due to legacy web apps that were working on IE an that probably won't work on Edge. Some users may have Windows 10 but their browser will be IE11.

Basically IE6 is back.

Internet Explorer never was evergreen.

[brianteeman]

@reinmar fair enough Maybe a little more publicity will achieve that

[duracell80]

We'd have to look at dropping CK Editor / Alloy Editor from our instance of Liferay DXP and move towards TinyMCE if our business direction required continued usage in IE. We'd have to move on to other solutions that weren't CK Editor.

If anyone has a time machine ... even though the IE7 team had good intentions we could just you know, well convince them not to do it. https://en.wikipedia.org/wiki/Internet_Explorer_7.

Would be a great episode of Dr Who ... titled "Who Broke The Internet?"