W3C home > Mailing lists > Public > public-htmail@w3.org > February 2014

Re: Introduction: Neil Jenkins, FastMail

From: Neil Jenkins <neilj@fastmail.fm>
Date: Wed, 05 Feb 2014 12:51:44 +1100
Message-Id: <1391565104.4870.79416549.2F46C737@webmail.messagingengine.com>
To: HTML for Email Community Group <public-htmail@w3.org>
On Wed, 5 Feb 2014, at 03:21 AM, Robin Berjon wrote:
> welcome! I have to say that I really like the JMAP draft that FastMail
> released not long ago.

Thanks! We're keen to push this along this year too; it will make it
much easier for new email clients to be written, and much faster (and
more bandwidth-efficient) for existing clients to sync email. It's early
stages, but we're hopeful we can get enough companies on board to make
it happen. We'll see.

> • Does <style scoped> help you in any way? Would you need
> something else?

It would help, but it only completes half the picture: we also need to
make sure that styles defined in the rest of the page do not apply to
the email message itself. This can be achieved by rewriting all the
class names and ids in the email on the server, in both the HTML and
CSS, to include a unique prefix (this is an approach we have used in the
past); however, this is just as much of a pain to do (and can break some
selectors), so doesn't really save us much on our current solution.

> • Regarding stuff like removing position: fixed, what if there were
> a way of indicating from a containing context that such properties
> (or in general positions outside of the box) are forbidden? Would
> that help?

Yes, it would be very helpful to be able to prohibit any drawing outside
of an element (overflow hidden doesn't quite do it).

> • I'm curious why you're not using an iframe to display the email
> content — is that for performance reasons? Or something else?

We used to do this, but switched for two good reasons:
1. Performance. We show messages threaded into conversations. If you try
   to render 50 messages at the same time, each in an iframe, even
   modern computers running the latest browser would grind to a halt. No
   such problem with the current method.
2. Printing. A lot of users still actually print their email (weird, I
   know), and iframes are all sorts of broken when it comes to printing
   in most browsers. You would normally get nothing beyond the first
   page. Now, we could do what every other webmail does, and force the
   user to open a special "print view" in a new window, but we think
   having a print stylesheet that allows the user to just go File->Print
   is much more elegant.

> • It's looking like, as a solution, it may not be here to stay, but
> would something like <iframe seamless> help you? If not, would
> something else of the same kind?

Unless it solves the two problems above, no.

> • What if browsers provided an API that allowed them to sanitise
> content for you (with some parameters allowing you to control the
> whitelist), would that help? Would you use it?

Potentially this would be useful, yes. Of course, we'd still have to do
the existing workarounds for older browsers for quite some time, but if
it was simple enough to adopt then we would definitely use it: at the
very least it adds an extra layer of security.

> • Do you use CSP? If not, is there anything to fix with it that would
> make it work for you?

We have tried to enable CSP in the past, but found it not to be viable
(if I remember correctly, the problem was to do with people's extensions
in the browser being completely broken with CSP enabled). This was over
a year ago though, and the implementations have improved a lot. We
should enable report-only mode again and see what comes up.

Received on Wednesday, 5 February 2014 01:52:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:54:17 UTC