4 ms·

More than anything, this thing shows the sad situation of CSS support in different email clients.

• Latty 11y ago
  Sad situation? I'd say it's limited for security and user comfort. I can't say I've ever felt HTML emails beyond basic text formatting and links improved my life.
  • CaptSpify 11y ago
    Although I agree with you, I generally should trust my email provider to not mess with my email, however I choose to receive it. Sure, html email is annoying, but let there be a flag or option for the user to decide to display it or not.
    • JoBrad 11y ago
      There are some good reasons why email clients do modify HTML: security is one, but they also have to make sure malformed HTML can't break the rest of the page. There are also reasons why they don't publish clear documentation on what they do to it, but this mostly means huge headaches for anyone who tries to create HTML email.
      • ceejayoz 11y ago
        > they also have to make sure malformed HTML can't break the rest of the page <iframe src="/actual/email"></iframe>
        • azinman2 11y ago
          Changes what you can then do with the email. If you want to hide quoted or let users select specific text for forwards, you're SOL.
          • ceejayoz 11y ago
            As long as they're on the same domain, you should be able to reach into the child iframe. Used to be a common technique for handling file upload progress before AJAX support for uploading became commonplace. The child can reach up to the parent via JS, too, but you'd want to sanitize any JS in an email anyways.
        • livingparadox 11y ago
          Anyone who doesn't do this is asking for trouble
        • mschuster91 11y ago
          Please, add a sandbox attribute on your iframes. I have outlined the reason for this below.
      • tehlike 11y ago
        > they also have to make sure malformed HTML can't break the rest of the page What do you mean? That's the point of iframe, so the email content cannot break email. We have object urls[1], and it's really not super hard to put emails into a different url to simply iframe src="" it. [1] https://developer.mozilla.org/en-US/docs/Web/API/Blob https://developer.mozilla.org/en-US/docs/Web/API/Blob
        • JoBrad 11y ago
          My first thought it that you may be looking at what is feasible today vs what was feasible for email clients (web or client) since they've been supporting HTML email. Email has been around a long time, and thinking of email as being a vector for security concerns has been a topic for even longer than consideration of browsers as a security concern because while you can "be smart" about where you browse, you can't "be smart" about what email you receive. Email that positions elements over portions of the email client or screen scrapes your email is a big deal, obviously. Also, I am not saying that this was the only way to mitigate this risk (Apple Mail seems to pretty much use an iframe in their client, whereas other email clients still munge the HTML (Outlook, Eudora, Lotus, etc). But it is the way that many did choose, and I can understand why whether or not I agree with how they did it.
        • tempestn 11y ago
          iframes have a number of real world usability problems. One example is that iOS ignores any sizing of the iframe, automatically growing it to fit its content, which could easily mangle the rest of your layout.
  • yoavm 11y ago
    How is Gmail not supporting 'box-shadow' or ignoring 'display: none;' but allowing 'display: none !important;' a security feature? Not supporting classes? Why does AOL messes with inline URLs (so that they stop working)? This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.
    • JoBrad 11y ago
      And then there's Outlook. My quality of life is so much better since I left the email marketing industry.
  • ArchReaper 11y ago
    This is sadly misinformed. Having had to create business emails in the past, it's frankly a nightmare, and I can't agree with anyone who doesn't see that.
    • gpvos 11y ago
      Having a universally implemented, and uniformly implemented, limited subset of CSS would actually improve the situation for you.
  • Pxtl 11y ago
    I could say the same thing about the web itself. Leaving Javascript out of email is just good sense. Leaving full support for HTML+CSS is not.
  • gohrt 11y ago
    "Limited" is OK. Inconsistent across mail apps is bad.