Re: Ideas for an Email Specification

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[1] 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.

Links:

  1. https://www.fastmail.com