[IDEA] Drop support for Internet Explorer after 5.1.23 release

[rmunn]

Is your feature request related to a problem? Please describe.
Microsoft will no longer support Internet Explorer starting August 17, 2021, and in fact their Microsoft Teams feature has already stopped supporting IE11 as of November 30, 2020. Supporting Internet Explorer is making TiddlyWiki code more complicated to write (for example, #5158 (comment) had to add extra code to support IE because it handles mouse click events differently from all other browsers), and as of November 2020 IE represents just 2.55% of global page views on desktop computers (just 1.13% of page views if phones and tablets are also included).

If Microsoft is preparing to drop IE support, I think we should too.

Describe the solution you'd like
Add code to the GettingStarted tiddler that displays a warning message if the current browser is Internet Explorer, saying "Internet Explorer will not be supported after (date and/or TW version number). Please use a modern browser such as Edge to use TiddlyWiki". (The name "Edge" will be a link to its download pages). Why just recommend Edge rather than Firefox or Chrome? Because anyone who's still using Internet Explorer is almost certainly not tech-savvy, and Microsoft has tried to make Edge feel the most like IE, whereas asking a non-tech-savvy person to switch to Firefox or Chrome will be more difficult because it will require them to unlearn more habits.

Then after the given date or TW release, stop supporting IE entirely. Do not test on IE, do not include any special code that handles cases where IE behaves differently from other browsers, and so on.

Describe alternatives you've considered
The alternative is to continue to include special-case code to handle IE quirks, which is IMHO more work than it's worth.

Additional context
#2278 was a discussion of which browsers and ES targets (ES2015? ES2016? Later ES versions than that?) should be supported, but it went nowhere. While it's worth revisiting that discussion at some point after the 5.1.23 release, I want this issue to be a more narrowly-focused discussion. Here, I just want to discuss whether anyone is still in favor of supporting IE after 5.1.23 is out the door. (I suggest not dropping IE support in 5.1.23 since that would potentially be a big change and I don't want to delay the 5.1.23 release). I know nearly all developers will all be in favor of dropping IE support as it will make our jobs easier, of course. But is there anyone who opposes the idea?

Also, I would like you (yes, you who are reading this right now) to think about the least tech-savvy people that you know. Are any of them still using IE, or have all of them switched to other browsers like Edge because Windows Update made the switch for them? If you still know even one single person who's still using Internet Explorer, and especially if that person uses TiddlyWiki, please speak up and let us know.

[saqimtiaz]

Perhaps canvassing opinion on Google Groups about IE support would be helpful as well. Opinions expressed here will always lean more towards the tech savvy side.

[Jermolene]

Thanks @rmunn.

Our de facto policy with respect to IE for some time has been to not knowingly break the compatibility we've already engineered, but not to test IE support in any concerted manner.

My rationale is that although it is probably rare by now for home users, IE is still widely dispersed in corporations for use with crusty old internal apps, some of which will be based on TW5.

It might be helpful to find out specifically what we could cut or simplify if we were to drop IE support. Searching for $tw.browser.isIE brings up a few bits and pieces, but I don't see opportunities for particularly great savings.

I think that our early dialect of JS is a more limiting constraint, and so I am in favour of rebasing our target platform for something like v5.2.x.

[saqimtiaz]

I've been using IntersectionObserver with some success to deal with very large numbers of tiddlers/widgets to be rendered, by delaying rendering until they are near the viewport. This is an alternative to the approach used in Dynaview which has higher overhead.

I think we could leverage this to good effect both as an alternative means to what Dynaview does but potentially even a few places in the core. Browser support is good apart from IE which does not support it at all.

[Jermolene]

I've been using IntersectionObserver with some success to deal with very large numbers of tiddlers/widgets to be rendered, by delaying rendering until they are near the viewport. This is an alternative to the approach used in Dynaview which has higher overhead.

I think we could leverage this to good effect both as an alternative means to what Dynaview does but potentially even a few places in the core. Browser support is good apart from IE which does not support it at all.

Good point, that was indeed exactly why I didn't use IntersectionObserver in DynaView. It was originally created for a client project that needed as broad browser compatibility as possible, but that was three years ago now.

[pmario]

There is a nice article which may be interesting: The baseline for web development in 2022

Especially the Conclusion - about "build target" is interesting:

Conclusion

Let’s look at the report card.

• We’re not answering to the users’ needs: Especially in terms of performance and a11y.
• We’re overusing JS: Both in our dependencies and in our own code.
• We’re underusing HTML and CSS: This is partly due to IE support, but now that we don’t need to support IE there are many features that become usable.

Here are a few overall tips for people who want a starting point on how to improve:

• If you can do something using CSS use CSS: There are many things that previously were only achievable using JS that can be done with only CSS nowadays. By doing that you can partly reduce your JS code.
• Evaluate your toolset: Many newer tools have better performance baselines compared to older ones, and not every project needs to be an SPA. Some of the non-framework-based SSGs like Hugo, Jekyll, or 11ty work great for those use cases.
• Build for modern browsers: Drop IE support and set your build target to ES 2017 or even 2018. Just doing that might get you bundle size improvements of up to 20%.
• Consider a11y from the beginning: Having a11y in mind from the planning and design stages is the ideal scenario. Starting by improving things such as contrast rates, font sizes, semantic HTML usage, and keyboard navigation can make a great difference.

[rmunn]

New news (if that's not redundant) supporting the idea of dropping Internet Explorer support: https://docs.microsoft.com/en-us/lifecycle/announcements/internet-explorer-11-end-of-support

Summary: starting June 15, 2022, Microsoft will no longer support IE 11 at all. For those businesses that still want to have a browser that behaves like IE, they've added an "IE Mode" into Edge, which works only on sites that you select. (Or your IT department selects: they have an "Enterprise Mode Site List" feature where the IT department can build a list of sites and then push that to all the Windows computers on their network).

I don't know how aggressive Microsoft is going to be in forcing that update on people, but starting in mid-June, it will become pretty safe to assume that even those places that mandate IE will be using MS Edge, and will be able to turn off IE mode in the cases where it becomes necessary.

You've mentioned that IE11 is still quite common in the UKs National Health Service. I'd be interested to know whether that's still true after June 2022. Because I would love to see features like Server-Sent Events being possible in TW (which would enable scenarios like "user A and user B both have the same wiki open, and user B gets to see user A's edits in near-realtime), which will only be possible once you feel ready to drop IE support. (Since IE does not have, and will never have, the ServerEvent API).

[pmario]

... Because I would love to see features like Server-Sent Events being possible in TW (which would enable scenarios like "user A and user B both have the same wiki open, and user B gets to see user A's edits in near-realtime), which will only be possible once you feel ready to drop IE support. (Since IE does not have, and will never have, the ServerEvent API).

IMO you should open a new issue, if you want to discuss SSE again. ... See this discussion: #5853, which did implement SSE for TW, but was completely removed. ...

Arlen did create a plugin: https://github.com/twcloud/tiddlyweb-sse ... which works in a similar way as the existing TW "timeout / poll" mechanism. ... So it doesn't really use the advantage that SSE could bring to the table.

[Jermolene]

Hi @rmunn that's encouraging news, and let's hope it does indeed drive more organisations towards taking IE out of service.

In the specific case of SSE, I wouldn't see it as a problem if some new SSE-based functionality didn't work in IE.

[rmunn]

Internet Explorer has been officially End-of-Life'd now: https://blogs.windows.com/windowsexperience/2022/06/15/internet-explorer-11-has-retired-and-is-officially-out-of-support-what-you-need-to-know/

Over the next few months, opening Internet Explorer will progressively redirect users to our new modern browser, Microsoft Edge with IE mode. Users will still see the Internet Explorer icon on their devices (such as on the taskbar or in the Start menu) but if they click to open Internet Explorer, Microsoft Edge will open instead with easy access to IE mode. Eventually, Internet Explorer will be disabled permanently as part of a future Windows Update, at which point the Internet Explorer icons on users’ devices will be removed.

I don't yet have any data on how quickly Microsoft will roll out that "redirect to Edge when you click on the IE icon" feature they mentioned, but it means that even organizations that don't want to spend the time on any kind of switchover will end up switching to Edge, in most cases without even knowing it. So the only potential downside I'm aware of to dropping IE support has just been removed. 🎉

[Jermolene]

So the only potential downside I'm aware of to dropping IE support has just been removed. 🎉

Dropping IE support in the Getting Started tiddler, as proposed in the OP, is very straightforward and I think could be done straightaway.

Are there steps you'd like to see in terms of dropping support for IE in the core code?

[rmunn]

Are there steps you'd like to see in terms of dropping support for IE in the core code?

I remember there were several Javascript idioms that I couldn't use last time I implemented some feature, because IE didn't support them when all other browsers did, but I don't remember what they were. If I find any in the future, I'll list them here.

[rmunn]

I just found another reason to consider dropping IE support: the browser compatibility list at MDN, which I've always consulted to verify if the code I'm writing in my PRs can run on IE, no longer lists IE at all in the table! See, for example, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray — the desktop browsers listed are Chrome, Edge, Firefox, Opera and Safari. It's no longer possible to use MDN to check if your code will run on Internet Explorer. (I did find out, by using an MDN mirror site that wasn't fully up-to-date, that Array.isArray runs on IE 9 or later).

[Jermolene]

Thanks @rmunn that's encouraging.

It occurs to me that there are some indications that there are still people using the "HTA hack" for saving under Windows; we get a trickle of user posts mentioning it.

[pmario]

I also use MDN as my main reference for web related info.

It's not only, that IE compatibility info is gone, they also "modernized" their static code examples, where I did raise a concern about "code example consistency"

see my post: https://github.com/orgs/mdn/discussions/143#discussioncomment-3112399 ... and the responses to it.

It seems they finished this particular project. So everything discussed there and considered "modern" code will probably have been implemented MDN site wide. ...

So there is a very high chance, that most of the code examples there will not work for pull-requests against TW core code anymore.

[pmario]

@rmunn I think we can close this issue. IMO we do not support IE anymore.
@Jermolene ?

[Jermolene]

@rmunn I think we can close this issue. IMO we do not support IE anymore. @Jermolene ?

Our position hasn't changed since my earlier comment:

Our de facto policy with respect to IE for some time has been to not knowingly break the compatibility we've already engineered, but not to test IE support in any concerted manner.

I think this ticket is still current; we still have to reach a decision about actually removing the code that provides IE support.

[Leilei332]

If we need to drop IE support, I think we should follow these steps:

1. Mark IE as deprecated in docs
2. Declare not supporting IE
3. Remove IE related code (like fsosaver) in the next big version

[Leilei332]

I think we had better drop support for IE as early as possible, so that we can implement functions including these:

• [IDEA] Migrate copy to clipboard function to use native Clipboard API #8615
• [IDEA] Support Web Custom Formats in Importer to allow for storing Tiddlers in the Clipboard  #7208
• [IDEA] The core themes should use CSS @layer to improve customisability and readability #6978
• [IDEA] Apply :where() on all of the tiddlywiki styles to ensure the lowest specifity possible / avoid clash with user customisation #8591
• event.keyCode is deprecated - should we use event.key in `$tw.keyboardManager`? #8753
• Adopt Feather/Lucide icons #7652
• Updating the JavaScript dialect used by the TiddlyWiki core #7353
• Use sticky flag to improve regexp search performance #7297

[Jermolene]

Thank you @Leilei332 it is very helpful to see those tickets listed together, and a good reminder that this decision should be driven by consideration of the benefits to the majority of end users.

In a general way, I think we're ready to start considering a v5.4.0 release that trades some backwards compatibility for some overdue improvements such as more modern CSS.