Internet Explorer 11 (IE11) to be retired on June 15, 2022
blogs.windows.com
blogs.windows.com
But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.
https://www.windowscentral.com/project-monarch-outlook-web-u...
IM is one of the last places on the internet not filled with automated crap, advertisers and spam. And to be fair, some of that automated crap I actually want and browse through at a later time but IM explicitly separates real time messages and newsletters.
Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed.
A few thoughts on implementation:
- Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail)
- For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet.
- A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?")
- When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant.
- When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant.
A few tricky areas:
- Mail clients would need to agree on a Markdown dialect, especially for extensions like tables.
- Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting.
- For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers.
- To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.
Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
* iframe content inside message is editable after message sent.
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
You can already use url() to load background images - seems like this is a solved vector.
> * iframe content inside message is editable after message sent.
Does this really increase the attack surface area, since you can't execute javascript from the iframe?
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
No, because that's not in the HTML/CSS spec and modern browsers don't support it.
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
Background image with url() is very easy to be whitelisted because it's very similar to <img> tag.
> Does this really increase the attack surface area, since you can't execute javascript from the iframe?
Sorry, this concern isn't about security for browsers, but for text editable email without indication. Maybe you can argue that it's not a problem because external image is already replaceable, but IMO it's more problematic.
> No, because that's not in the HTML/CSS spec and modern browsers don't support it.
Blacklist approach means that any tags just work unless explicitly specified on blacklist. "Not in spec" won't help.
> Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
That's thanks to whitelist approach.
EPUB3 supports JS.
That's kinda funny given how my Calendar.app event notes are just full of unparsed HTML tags
Though I don't know which is worse, putting HTML in calendar invite descriptions, or refusing to render basic tags.
For a while, people would be sending both text/html and text/html-for-real, but eventually we’d maybe be able to switch to only sending text/html-for-real (while also continuing to send text/plain for fallback.)
text/email Mozilla/5.0 (KHTML, like Gecko)
Eventually, if everybody switched to sending text/html-for-real first, maybe the email clients could follow along and make text/html also mean "the newest and most featureful version of HTML5"; and then we could all revert to just calling it text/html.
Rather than a distinct MIME type, I believe it could also make sense to borrow the HTTP header X-Content-Type-Options: nosniff (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...) into the MIME envelope of the text/html document, to signal that this envelope is "really" using HTML, no second-guessing. (This is how the header was used in IE8: to tell the renderer to explicitly not trigger IE historical-renderer compat mode.)
That might get into a situation where the message has two MIME bodies that are both text/html, though, and I'm not sure existing clients have been written to cope with that. A well-engineered solution would work with existing clients (by having them ignore the body of unknown-to-them media-type, and render the old fallback body of known media-type.)
For an application which has rendering HTML content (emails) as its primary function, being a PWA and using something like Electron actually sounds like a good choice.
Hehe, I also moved to an Outlook company a few years back. I’ve had to switch completely to the Outlook Web App (OWA), the native app gets too bogged down after a while, and it’s frustrating to deal with Outlook native across multiple machines. My Outlook experience was vastly improved when I stopped using the native client. And there are a lot of reasons I prefer Gmail as well, Outlook seems to lose threads easily, the spam filtering isn’t as good, and it has all kinds of unintuitive UI quirks and gaps.
Also, if it's going to be a packaged-up version of the Outlook webapp, I'm going to lose the global unread mail folder, which is going to kill me, given the way my inbox folders and rules are set up by customer.
- ed
for some reason I have it in mind as IE5.5 specifically that was The Great IE.
I won't argue that it wasn't decent at launch, but MS kept support for that browser around way too long and failed to actually roll out support for new features that customers desired. I believe it was the era of IE6 specifically that led to the proliferation of top-right-corner.jpg which was an absolute abomination.
But from my stand point then, It Just Worked.
I switched to IE until the Mozilla suit released and later on switched to Firefox 0.something - it was amazing how fast it was compared to both IE6 and Mozilla.
The issue was the length of time that it stuck around for.
I hated it but it made me a lot of money for many years, mostly thanks to governments requiring IE 6 support. LOL
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I also vaguely remember jwz writing about the experience of developing it.
I don't broadly support Mozilla's aims (I also don't not - I'm an owner of a 1st-gen Firefox phone, for example), but we're just talking browsers here.
IE 5, 5.5 and 6.0 (this last one at least initially, but clearly it stayed around too long without development) were noticeably faster and more user-friendly in my experience.
My biggest ever frustration.
Don't you dare include me in "our" 8)
My first browser was telnet (1992ish) From 1993 onwards it was all a bit weird in internets land.
For me the golden time for wwwbly_internets was around 2000-5 or so. /. was still (just) worth reading, FB was still a bulge in MZ's trousers. Google was cool, Amazon was clever, Apple was cool. The www was still interesting - US frontier like.
I am of course joking. Today's www is not the same as that in say 2000. Google is not cool, Apple is not cool, Facebook is unpleasant, Amazon is not cool and quite odd.
I guess your damned if you update and damned if you don't.
And it's not necessarily just old stuff, either- there are brand new NVRs and cameras going in today that require IE and some godforsaken ActiveX control to work. IE is going to be around for a long time.
Maybe that's why my replies from Thunderbird using interspersed posting shows up empty for some Outlook users.
I feel you, and if you're an enterprise user still on the last LTSB release (1803) then yes - Outlook is still using a trident based browser.
If you're on 1903 or above, though, my understanding is that you're now on a WebView2 engine running roughly what's in Edge right now: https://docs.microsoft.com/en-us/microsoft-edge/webview2/
I know for a fact that our company's product for Outlook (an addin.js extension) has suddenly started working for customers in Outlook when they upgrade, and we're not IE11 compatible.
While IE11 as an independent program is going away, the rendering engine is still around for 8+y.
Here's hoping that this deprecation removes the expectation that things support IE11, however!
You can even disable the ability for users to change it, forcing IE mode on sites where it doesn’t work.
It’s my second most hated abuse of group policy.
https://docs.microsoft.com/en-us/openspecs/ie_standards/ms-i...
It's not just about doing something new; a bad codebase that I don't have the opportunity to genuinely improve is probably the most miserable type of project I can possibly think of
Good software engineering is all about building something that meets current business needs while being flexible enough to adapt to future needs. When you lose this flexibility, you need to refactor or changes become too difficult to implement.
IE11 isn’t getting any new features. It’s in maintenance mode. Cleaning up the code in major ways at this point would be a waste of time.
Realistically it'll just be part of a far larger security team that fixes bugs in a large number of software preferably prioritising bugs based on severity where there's always going to be something better to do than mess with old codebases.
That being said, our company is deprecating IE11 support in October and I already have the PRs ready to rip out some of the code that bloats our JS/CSS with polyfills.
Anything new can safely ignore IE11, because Edge won't be using the IE11 engine for it.
This is great, because it'll get corporations to replace the actual IE11 executable with the Edge executable.
I’m probably just cynical, but nothing caused corporations to get rid of IE11 before, and nothing will now.
Working on an enterprise b2b web app, I’m going to have to support IE11 indefinitely.
Yes it will. Microsoft is gradually pulling out all support for it, with this year being the big start of that.
Very soon, it'll become more work for admins to maintain IE11 installations than it will be for them to migrate to Edge with IE11 compatibility mode. Admins tend to choose the path of least work.
You're only going to need to support IE11 indefinitely if your enterprise app requires IE11. Otherwise, your company is probably going to be able to pull the plug at some point in the next 2 years, depending on your specific customer base.
Microsoft has a long reputation of fixing bugs caused by other people's software and their incorrect assumptions about Windows.
There are also timelapses for those not into having a multi-hour windows nostalgia marathon.
Follow up - Windows 1 to Windows 10: https://www.youtube.com/watch?v=PH1BKPSGcxQ
Luckily it only to last another year or so before we replace this product. Some people don't understand the cost and effort required to replace some of these older but hugely important legacy products.
Always sounds good in theory but when trying to maximise reach, it can be hard to instantly tell a whole bunch of the web, who might be running old PCs, that they can't use your site any more.
Also, when you have large corporate customers, you often do not have enough muscle to tell them that unless they upgrade their client browsers, they can no longer use your service.
That decision might sound simple but there can be loads of regulatory or accreditation hurdles to overcome to use a new browser and it can affect 1000s of corporate employees.
https://docs.microsoft.com/en-us/microsoft-edge/web-platform...
Do you know if there's a way to see that XML list they mention anywhere publically? I can't find a link to it on that page.
I guess it should be possible to spin up IE11 in a VM on macOS and inspect the network, but would be nice to take a look and see which sites are on there.
> * Shows an IE user a message suggesting the user should use a different browser for compatibility reasons.
Looks like you can have your site automatically added to the list by telling your users to use Firefox instead of IE.
Depends on the constraints. Qt was around and mature for many years in 2006. Ruby on Rails had it's first release mid 2004. Django mid-2005.
Again it depends on the constrains, what you can "the best choice in 2006" is limping now. Meanwhile an app built in 2006 on Qt/RoR/Django would be on a platform that is currently still being considered for green field devt.
Without knowing all constraints I'd be willing to say that IE+applets was not the best choice in 2006, neither was: GWT, WebSphere or any of the MS GUI toolkits around in that year.
I'm still on the fence wrt Vaadin. It was not around in 2006, but soon after. Never used it, but it seems to still be actively maintained to this day.
But the lack of obviousness does not make IE+applets the best choice in 2006.
The timescale for a supplier to be in-business in order to prove their safety-critical credentials, the time it takes experienced developers to learn a language or framework and prove that it works, the time it takes to find, specify, build and deliver a project in these circles means you would be hard pushed to find anything that is less than 10 years old being used outside of startups.
Also, if there's a genuine need to keep IE around for longer, then you have some options, e.g. deploy Win 10 LTSC for specific legacy use-cases, or publish IE11 via Citrix.
now it's time to sell it hard to management
'In development'. Does this mean v1 hasn't even shipped yet?
yes
Edit: I've seen a later comment mentioning it was started a while ago. But still... this is a dead platform. To me this is on the level of launching a new app targeting Windows XP. It's just a disaster
None of it could be upgraded.
Which would have been fine except that it had dependencies, and those dependencies had dependencies, and... you get the idea. I got the distinct impression that were it to fail or be unplugged every system in the business might slowly and inexorably fail over a period of days or weeks, eventually grinding all trading activity to a halt.
They were trying to figure out what to do about it and, fortunately, the guy in charge of replacing it really seemed to enjoy that kind of problem but, for all I know, they're still running it.
People should know that hardware will become obsolete or fail, that software will become unsupported, the supplier might go bust etc.
You need to be able to run generations of IT in parallel so that you always have newer hardware/software getting used/proved alongside the old nonsense and if you will need to replace an aging system, you better have seen it coming enough years earlier to give you time to find a replacement.
Also, large corporates have a habit of over-customising what they want so a new system has to be completely bespoke = slow and expensive to replace.
Why?
Surely it's not a greenfield project.
For that type of project, it might be worth it to write a detailed spec for how the back-end talks to the front-end so in the future it's possible to write a more modern client.
All of that on top of a system which has likely changed in the intermediate years. Basically, you might as well milk the existing system for as long as possible and then replace it with a completely new system that probably runs on newer hardware (1990s instead of 1980s), is much more maintainable and does things in a more modern way.
Not sure when was that app written, but the control unit was assembled just months ago.
I see no devastation here...
It was one of the most satisfying tasks I've ever received.
I can't wait to go through the app with a machete and whack away all the sloppy IE compatibility code.
This brings me hope. But only a little. I’m sure they’ll find a way to keep running it.
Do you know why that is?
I noticed that there are prominent links to a Korean and Japanese version, presumably because Internet Explorer is still used to a large extend in those two countries. Korea had some crypto stuff that only worked in IE, but that was years ago. Why haven't those markets moved on more modern browsers?
As for Korea, IE was mostly for ActiveX, but now most Korean website supports modern browsers ie Chrome.
This should be, and always should be, the case. Chrome is such a bad actor in allowing userspace install, we mark it as malware to prohibit unauthorized installation. Chrome Enterprise policies don't seem to be able to disable this, marking it as malware is the only way out...
That said, we offer two modern browsers to everyone in our environment, Edge and Firefox.
Imagine Google would not support IE11, I'm sure the pressure to upgrade these browser would be much higher (not sure about the health care space though)
Also...no? Why would it be?
To the extent (if any, though I'd be surprised if there were none) IE11 doesn’t support standards required effectively, if indirectly, via the HITECH guidance on secured PHI, IE11 use could have some some adverse consequences under HIPAA (and, as a SaaS operator with a BAA that would include the vendor, not just the customer), but not in and of itself noncompliance for use or support. Mostly just making it more likely that situations would become reportable breaches.
relegated to old grayhair horror stories.
We nearly lost the damn open web to the horror of IE6 and the peak "embrace, extend, extinguish" version of Microsoft.
Now, of course, we're happily creating another browser monoculture and handing the web over to Google. This time, we're doing it with a smile instead of a grimace.
Unlike IE6's reign of incompetent terror, Chrome is actually a competent browser. Techies are embracing the takeover instead of fighting it. It's guaranteed to succeed.
IE6 was also a good browser. It didn't stay a good browser over the 5-10-15 year lifespan it had (depending on who you ask) but at the time of release it was easily the best.
But it was pretty bad in other ways: security, stability, etc.
Seems like a better approach in every way than the old mosaic/trident closed source mess.
Sure, you can look at (most of) Chrome's source code, and fork it all day long if you want. But it will amount to little when it comes to actual control of the web. You simply won't have the marketshare to steer the direction of the web standards themselves.
The end result will be the same as we suffered with IE's dominance: de facto control of the web by a single entity.
But at least the ride to hell will be nicer.
Woo. And, indeed, hoo.
> for certain versions of Windows 10
Ah. And there begineth the weasle words. I'm guessing there will be significant organisations in finance/wealth management (our general area) and other industries that will still demand IE11 support for some time after that date.
I think first a combination of our move towards "more smaller clients, not being beholden to a few large ones", the reducing budgets if those big clients, and the fact the others are more up-to-date, will mean we'll be able to say "Support IE11 or will go elsewhere? OK then, see you around." long before IE11 really exits the industry. Whether the company will have the balls to go through with that, is something I'll find out in future, but I'm allowing myself a little hope.
I can have some sympathy to support IE for some cash-strapped local government department struggling to keep their old systems running with duck tape and prayers. "Finance/wealth management" is exactly where that sympathy stops.
After fighting with QEMU and getting Windows 98 4.10.1998 up and running, the wupdmgr.exe stub that it ships with just detects if the machine is connected to the Internet, if it is, it opens MSIE and sends you to a page that doesn't exist anymore.
If you're not connected, it loads a local webpage in MSIE telling you about how great Windows Update is. Funnily enough, that page also includes instructions to get rid of the Windows Update launcher should you not want to see it anymore.
Makes me think of this: https://ritholtz.com/2013/07/organizational-charts-of-amazon...
These days, sites and apps that support FireFox/Chrome tend to test only on latest versions. Which come out frequently and can and do break things. Supporting IE11 means it works in IE11. Supporting FF/Chrome means it mostly works in the latest tested version.
If devs were more aware of Firefox ESR version and tested against it, we could have more stability again.
(Firefox is a close second but is clearly starting to become user-hostile too... and now you may realise much of why they want to kill IE and dumb down Firefox: herding users is easier when they're turned into obedient and docile consumers, instead of masters over how they decide to consume your content.)
Did you completely miss IE9?
Much live a headcrab, the ActiveX takes over the the full device context and reaches deep into the OS. I CAN pulp my own WM messages thank you very much Mr browser ... Brakes my alt tab from time to time, can't grab focus from a miss Z'd dialog. Yes... Nostalgia Nostalgia Nostalgia
WebDriver: https://developer.mozilla.org/en-US/docs/Web/WebDriver
Marionette: https://firefox-source-docs.mozilla.org/testing/marionette/I...
Puppeteer: https://www.infoq.com/news/2020/04/puppeteer-3-firefox-suppo...
I haven't used these tools, so I don't know which is "best" or why so many different tools are needed. :)
That's a complete non-starter, compared to automating IE that just requires our .exe to create an IE object via CoCreateInstance(CLSID_InternetExplorerMedium ...), and no additional installation by the customer organization.
People talking about certain spaces (eg healthcare) where Citrix on windows server is the norm are going to support ie11 for the lifespan of windows 2019. So don't pop the cork just yet..
They sent me a screenshot of what should be a form in a modal but the modal has failed to load so it has loaded just the form in a new page looking pretty unstyled. The JS for the modal uses fetch() so possibly why it broke.
I'm 95% sure that the browser in the screenshot is IE10. I pointed them to this announcement if only to make them aware of the security risks in running IE10 but it beggars belief that anyone would choose to run IE10, individual or enterprise.
Example: Office 365 OWA doesn't work well on modern browsers other than the latest version of Edge on Windows. But it does work fine on browsers that are older or pretend to be older! I'm technical enough to spoof my user agent, but Mom & Pop are just going to say "I don't like the new one, it broke stuff" and that will be that.
You can add on top of that the rebranding they went through. If they had just done what they did now, and shipped the old rendering engine inside the new one as some kind “legacy mode” that sites could request then everyone else could have moved forward years ago and not had to deal with a stagnant browser.
If I pretend my user agent is from circa 2012-2013 (e.g., Internet Explorer 10), it will default to an older interface that has marginally fewer features and is much, much more performant.
I almost wonder if at the time they were enabled, before people found the video
It also paved the way for technology to focus on security, standards and most of all, a better and standardized approach for browser technology.
Even mac users had to use IE. I never figured out how they were running IE on the mac, but there it was running in all its glory.
https://steamcommunity.com/app/34330/discussions/0/864947668...
And I still remember the print ad with the launch of Firefox 1.0.
M$ still have a lot to do to redeem themselves.
It is a victory and not an empty one. Firefox is the most independent among last remaining browsers. It is a good browser and an important alternative now that most other major browsers all use the same engine.
What is the next thing we should wish to see die on the internet?
- DOM
- CSS (first browser to support CSS, to be more specific)
- Events
- IFRAMEs
- AJAX
- favicon.ico
https://docs.microsoft.com/en-us/office/dev/add-ins/concepts...
Well, you could argue we're already doing that, considering its influence and how even Microsoft yielded and made Edge Chromium-based.
Why was it removed?
It is annoying when we can quickly proof up software, and specialized utilities when consulting with business. It is wayyyy to much work to port from IE to Edge though.. yeesh, waste of my productive time.
It’s way too much work to port your app? Well guess it isn’t that important after all. Because whether you want it or not, IE is a dead end and it’s going away.
I wish they would provide the opposite, Edge/Chromium engine in an IE skin/UI.
Now ship WebView2 with the OS in a reliable way that people can use.
we will miss you
the last (worthy) MS browser; it is gonna die
-- lever.co job posting
I recently started working on a new project that's running on Windows Server 2019 and the experience so far has been absolutely terrible. One Windows related headache after another.