If you've ever made a custom email you'll know that there are significant limitations in you need to be aware of.

The most obvious limitations being:

  • No support for Javascript in emails
  • No support for internal CSS (CSS placed in the HTML file header). Its rather understandable that external CSS is still not supported.
  • Email browsers encourage the use of HTML and CSS coding that is now considered deprecated and bad practice. For example; using tables to organise content rather than divs with CSS (float, etc.). Also as an example; the strict/over use of inline CSS
  • No support for forms

Whilst its understandable that early browsers would not support Javascript or CSS. Why do these limitations persist in modern browsers? What are the technical purposes (if any) that modern email browsers still have these limitations and inconsistencies with web browsers?

To point out the most obvious reason Javascript was/is not supported: Security. But as Internet Explorer has shown; when dealing with the security issues around ActiveX (I think thats what it's called?) they didn't ban or remove Javascript completely - they took other actions to resolve the security problems. So why hasn't the same approach been taken with Email Browsers?

  • In addition to security, I think some of it is related to the self-contained nature of an email. You don't want your referenced resources disappearing. So if that's the case, is it really inline CSS that's being promoted, or just making sure the style is defined within the document, etc? Also, have you considered that web browsers are not the only email clients out there? I would argue that there is greater diversity in the email client ecosystem than in web browsers. – J Trana Sep 20 '14 at 2:12
  • 2
    If you think no programmability via javascript is a limitation of email, then our conceptions of email are so different that I doubt we could have a productive conversation about it at all. – Kilian Foth Sep 20 '14 at 10:15

Unlike webpages, e-mails are:

  • Primary intended for basic communication. The most basic form being plain text, some features from HTML can empower the users of e-mails, but they probably won't use (or won't use properly) every feature available in HTML and CSS.

    In other words, being able to make text bold or italic or to make it blue and bigger than the rest of the content is great. Being able to use CSS 3 transitions won't be useful.

    What about ads? Well, you don't need too much features neither. As I said, this is not a website. You don't need interactivity. You don't need advanced formatting. You won't send an e-mail which looks like this page, because the purposes are simply different: the home page of the website is here to showcase a product or a company; the purpose of an e-mail, on the other hand, is to communicate a piece of information. "Hey, we just released our new Cloud platform, come visit our site to discover it!" is a piece of information, and can be expressed as simply as I did: through plain text.

    What can't be expressed through plain text can be through an image. Most e-mail clients allow to display images, so you have an option you need. You want videos, sound, interactivity? Not a good idea, because e-mails are not a good place for that.

  • Displayed not only a bunch of browsers, but also multiple e-mail clients, each one having its own restrictions and its own way to render e-mail contents. Take Microsoft: they have already a hard time implementing the standards in Internet Explorer. Would they rather assign to their best developers to work on the next version of IE which would support better the standards, or rather move those developers to a team which works on Outlook Express?

    Moreover, you know the problem all front-end developers had a few years ago, right? Do we need to support Internet Explorer 6, since a large part of our users are still using it? Today, the problem was largely reduced. There are much less users of Internet Explorer 6, and I also believe that web developers are so excited by HTML 5 that they simply stopped to care about legacy browsers. But the same problem exists for e-mail browsers: I'm completely happy using Microsoft Office 2007 and see no reason to buy a new version; this also means that Microsoft Outlook I use won't be upgraded in the next five years.

  • Prone to spam. The fact that the system itself is so much misused by spammers as well as companies willing to track who actually read their marketing stuff makes e-mails the first target. This also means that e-mail clients should take care of protecting their customers. You have images such as http://tracking.example.com/?id=babc7b16-c9fe-448d-aa84-2ccd37df6db7? Well, I think I prefer viewing your e-mail without actually loading the images. You want to track how long I spent reading your e-mail? Luckily, my e-mail client doesn't run JavaScript.

  • Often displayed inside a page. Web-based e-mail clients may display the content of the e-mail inside a page, surrounded by the e-mail client commands and other content. In this context, JavaScript is out of question (imagine a security threat if an e-mail can do redirects: so I click to read some spam, and see that my GMail suddenly disconnects and presents itself with a form asking me to provide my password to log on again). Full CSS support is problematic too: an attacker can make a part of the e-mail look like GMail interface.


Lack of need and use of protocols that don't support or reflect that method of communication. The separated actions of sending and reading.

Also the reading device could be any one of hundreds of different devices and the only medium really guaranteed to work correctly on all of them is text. Plus it will work in very low bandwidth conditions.

Not the answer you're looking for? Browse other questions tagged or ask your own question.