Re: Ideas for an Email Specification

I absolutely love this dialog.

Some thoughts:

“…not going to support anything the browser its running in doesn't support.”

This is one of the many reasons we need specifications and a commitment to standards. In all current cases in all current webmail clients, the webmail client supports only a small fraction of what the browser supports. As a community of email marketers, developers, designers and advocates, we are not suggesting any case where webmail is more capable than a browser.

“Outlook is awful because it uses Word as a rendering engine; a specification is not going to help change that. Either they will switch to the Edge rendering engine or they won't.”

This is precisely the result of a lack of specifications and standards. Microsoft has made a business decision to use the Word rendering engine based on the criteria that it meets their own standards – not the world’s. If we as a community publish a set of standards, and they are adopted by the other leading email vendors, Microsoft will have a different set of criteria to weigh this business decision against. Additionally, they need to be invited (again) and lobbied into a collaborative role in crafting these standards.

“…there is no need to filter CSS. The only thing you might do is block external content…”

This is a key issue that needs to be specified, as marketers and developers wish to be able to request external style sheets for myriad use cases. Examples: loading web fonts; publishing updated CSS so subsequent or time-based opens display unique styles or content; running developer-focused contests like the famed Litmus Golden Tickets, etc.

“…important that no scripting content runs so it can't steal the session, make API requests etc…”

We are so far away from basic display solutions using simple HTML and CSS, that I personally believe that scrips and APIs are years away from entering the discussion.

“HTML tags and attributes are of course filtered via a whitelist, and the same applies to CSS properties…”

If this is true and necessary, it needs to be documented and substantiated, and all vendors should be able to refer and adhere to the same set of whitelist standards. Then, as needed and well documented, they would append the master with their own whitelist – much like a branch.

“…without involvement from the other major webmail vendors (Gmail, Yahoo and Outlook.com in particular), this work is unlikely to actually change anything.”

I believe involvement from all email vendors – webmail and native – is precisely the will, intent, and hope of this group. Representation from browser vendors in the vast library of HTML and CSS specifications (W3C and WHATWG) is the industry norm and expectation. It should be the same for email vendors. I expect Apple, Google, Microsoft, Yahoo (who combined, hold the top 10 market share) and others to collaborate in the process of drafting, editing, publishing, and of course adopting specifications for HTML and CSS in email.

“…if we build it, they will come.”

Again, I think we need to get them to come to the table, so we can build it together.

Suggested channels to reach Microsoft Outlook Developers:

Thom Gruhler, CVP Apps and Services at Microsoft Corporation [linkedin<https://www.linkedin.com/in/thom-gruhler-98286aa>]
Julia Foran, Senior Program Manager at Microsoft [linkedin<https://www.linkedin.com/in/juliaforan>]
Microsoft Office Dev User Voice channel: https://officespdev.uservoice.com/
Stack Overflow: http://stackoverflow.com/questions/tagged/ms-office
Office 365 Technical Network (Yammer): https://www.yammer.com/itpronetwork
MSDN Forum: https://social.msdn.microsoft.com/Forums/office/en-US/home?category=apps,officedev,sharepoint,exchangeserver,lync,msproject
Outlook Dev: https://dev.outlook.com/
Outlook & Exchange Dev Blog: https://blogs.msdn.microsoft.com/exchangedev/

Thanks,


Charles Hall
UX Architect, Technology

t / 248.203.8723  m / 248.225.8179
e / charles.hall@mrm-mccann.com
skype / charles.h.all
280 N Old Woodward Suite 300, Birmingham MI 48009
w / www.mrm-mccann.com

[cid:2DB38BEF-C763-4EC7-A82B-5342FFC93D55]
Creativity. Technology. Performance.

From: "Rémi (HTeuMeuLeu)" <remi@hteumeuleu.fr<mailto:remi@hteumeuleu.fr>>
Date: Friday, July 22, 2016 at 5:03 PM
To: Neil Jenkins <neilj@fastmail.com<mailto:neilj@fastmail.com>>
Cc: HTML for Email Community Group <public-htmail@w3.org<mailto:public-htmail@w3.org>>
Subject: Re: Ideas for an Email Specification
Resent-From: <public-htmail@w3.org<mailto:public-htmail@w3.org>>
Resent-Date: Friday, July 22, 2016 at 5:04 PM

Thanks a lot for your insights, Neil. I'd just like to comment on your last sentence.

without involvement from the other major webmail vendors […], this work is unlikely to actually change anything

If we don't do this work, it is a certainty that nothing will actually change. As I previously stated, I'd like to believe that "if we build it, they will come". So I think it's worth trying.

-- Rémi


2016-07-13 5:24 GMT+02:00 Neil Jenkins <neilj@fastmail.com<mailto:neilj@fastmail.com>>:
Not that I want to pour cold water on this, but as one of the few actual implementors of an email client on this list (the FastMail<https://www.fastmail.com> webmail), I'd just like to reinforce a few points Chaals made earlier:

  *
In a webmail system, you are not going to support anything the browser its running in doesn't support.
  *
In a native client, you are not going to write your own browser engine, you will integrate WebKit/Blink or the system web view. Outlook is awful because it uses Word as a rendering engine; a specification is not going to help change that. Either they will switch to the Edge rendering engine or they won't.
  *
Beyond that, on a native client you can pretty much just disable JavaScript at the browser-engine level and you're done. The content cannot draw outside of the bounds of the webview, so there is no need to filter CSS. The only thing you might do is block external content until user approves, which can often happen at a network-intercept level from the web view. (This is why iOS/Mac Mail.app generally has the highest fidelity rendering.)
  *   In a webmail, you have to make sure the content cannot draw outside of the given area, and it's way more important that no scripting content runs so it can't steal the session, make API requests etc. iframes could in theory give you the isolation properties you need, but in practice are really slow (if you have conversation view and show multiple messages at a time, it can easily become unusable, especially on low-powered devices), are difficult to size correctly to the content, and completely break printing in pretty much all browsers (yes, this is still vitally important for many users).
  *   So if you don't use an iframe, you have to insert an arbitrary HTML document inside the current one, without the two interfering with each other, and without the inner one being able to draw outside of its bounds. This means either prefixing all the CSS selectors and rewriting all the ids/class names (and possibly other things depending on how the webmail is set up), or inlining the styles in style sheets (which loses some fidelity). HTML tags and attributes are of course filtered via a whitelist, and the same applies to CSS properties (normally the name only; the value doesn't matter, with the exception of negative margins in some systems, again depending on how the rest of the webmail UI is constructed). The whole sanitisation process is interesting, and documenting a "recommended' approach may be helpful, but realistically I'm not sure it's lack of knowledge that's holding back support in most major vendors.


Essentially what I'm trying to say is that without involvement from the other major webmail vendors (Gmail, Yahoo and Outlook.com in particular), this work is unlikely to actually change anything.

Neil.

This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message.  If you have received the message in error, please advise the sender by reply e-mail, and delete the message.  Thank you very much.