Re: Ideas for an Email Specification

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>:

> 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.
>