A summary of principles for writing HTML pages for email emails

Since HTML email is not an independent HOST on this website, it is dependent on others. So writing HTML mail is very different from writing HTML pages. Because all mainstream mailboxes for netizens will more or less filter the HTML mail they receive in the background. There is no doubt that JS code is strictly filtered out, including all event listening attributes, such as onclick and onmouseover, which are based on email security considerations. Not only that, the CSS code will also be partially filtered. What I want to talk about is how to write HTML emails that are not filtered by major mainstream mailboxes and can display normally.

First, let’s take a look at how the email displays HTML email. I have never made an email system, and the filtering algorithms in the backend of major email addresses are not so easy for outsiders to know. Therefore, we can only speculate through the front-end display to infer which writing methods are accepted by the email, and which will be filtered out. Through the analysis of gmail, hotmail, 163, sohu, and sina, I divided the email address into two categories:

Friends who are familiar with HTML know that iframe content is an independent document, and is irrelevant to the elements and CSS of the parent page and can be treated almost as an independent page. And if the email content is in a div, the email content is an integral part of the entire email page. Obviously, using iframe as the presentation method of email will be much more tolerant of email content, because it gives you a sufficiently independent space for presentation. And the div is not so polite. Just imagine, if you write this CSS in your email, will the font on the entire mailbox be 20px and it becomes messy:

<style type=text/css>

body {font-size:20px}

</style>

We need to write a unified email template that is compatible with each email address, so we must avoid the above external CSS writing method. In addition, styles similar to float, position, etc. that have abnormal content streams will also be filtered. If you write, it may affect the performance of external email addresses.

1. One of the global rules: Don’t write <style> tags or class. All CSS uses the style attribute. Use style to write inline CSS for any element that needs any style.

2. Global rule 2: Use less pictures. The email address will not filter your img tags. However, the system will often not load pictures from strangers by default. If you use a lot of mail messages with pictures, if the movie is not loaded, it will be extremely ugly and even unable to see the content clearly. The impatient user will delete it directly. Alt must be added to the picture.

3. Don’t write float and position styles in style, because they will be filtered. So how to achieve left and right layout or more complex layout? Use table.

4. The background can be set in the style content, but img will be filtered, which means that the background image cannot be set through CSS. But there is a very interesting element attribute, also called background, where you can define an image path. This is a good alternative. Although this function is limited, such as being unable to locate background images, it is better to have one than not. For example, to add a background to a cell, you must write it like this:

<td background=http://image1.koubei.com/images/common/logo_koubei.gif></td>

5. The email address in div mode does not support flash, and the iframe mode needs to be verified.

Finally, I would like to mention that sohu's email address is very weird. It will add a space after each text segment, causing the original normal layout to be unsubscribed and the line breaks, which will cause some layouts to be confused. Therefore, if you want to be compatible with sohu mailboxes, you should be extra careful when encountering some compact layouts, minimize the number of text segments and leave enough width.