Earlier quoted context omitted.
But Gmail is already a web app, and only supports a tiny subset of modern HTML and CSS. The limitation is of course arbitrary, it could in theory support any modern standards. But HTML mail is so quirky and full of hacks, that they probably have to do it that way to preserve compatibility. Apple's Mail app is one of the few modern mail clients that can render modern HTML/CSS
Given that email is MIME (i.e. you can add multiple “bodies” to a message, with different content-types, and the email client will select the best one it can render), you’d think we could just come up with a new content-type for email meaning “HTML, but for real”, and add that to email in addition to the current “HTML, but sucky” semantics we get from text/html-typed bodies. For a while, people would be sending both…
Internet Explorer 11 (IE11) to be retired on June 15, 2022
271–280 of 304 posts
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#272Earlier quoted context omitted.
I think that's what happens when your root is in enterprise software or at least some of your heritage is in enterprise. I have no great love for MSFT but I agree with you about their willingness to support things well past their expected expiration. IIRC they even went so far as to detect programs that used some "bugs" in earlier versions of Windows and emulated those same buggy behaviors just for those programs.
https://www.reddit.com/r/technology/comments/2hwlrk/new_wind... comes to mind, which explains (at least partially) why Windows 10 came directly after Windows 8.1
Microsoft has a long reputation of fixing bugs caused by other people's software and their incorrect assumptions about Windows.
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#273By moving to Microsoft Edge, you get everything described above plus you’ll be able to extend the life of your legacy websites and apps well beyond the Internet Explorer 11 desktop application retirement date using IE mode. Internet Explorer mode in Microsoft Edge will be supported through at least 2029. While IE11 as an independent program is going away, the rendering engine is still around for 8+y. Here's hoping th…
I think it will. Just tested the IE mode, you need to manually enable it for every time. I think it's annoying enough.
https://docs.microsoft.com/en-us/openspecs/ie_standards/ms-i...
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#274Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#275Earlier quoted context omitted.
https://youtu.be/l60HHWWo9z4 There are also timelapses for those not into having a multi-hour windows nostalgia marathon.
I clicked your link thinking it was the time lapse version, but it is over 10 hours.
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#276I smell a lot of nostalgia in this thread, and rightfully so! IE has been a terrible browser, but it was our terrible browser. But fear not! Outlook still uses the HTML parsing engine from MS Word (!) to display your HTML emails, and it's not going anywhere.
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.
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#277Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#278Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#279Earlier quoted context omitted.
When Outlook becomes a PWA (currently in test, I think it's probably two-three years from stable), it'll be rendering mail with all the functionality of Blink. Which depending on your point of view, means a sigh of relief or time to buy more RAM. https://www.windowscentral.com/project-monarch-outlook-web-u...
Wow this is awful. I just moved to an outlook company after years on google. It’s so nice having my mail client be native.
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.
Re: Internet Explorer 11 (IE11) to be retired on June 15, 2022
#280Earlier quoted context omitted.
There are good reasons to reject a lot of it. You don't want JS running in an email for example. Or even some of the fancier CSS abilities.
But then why have HTML email at all? You could just write in markdown.
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.