Content deleted Content added
←Blanked the page |
Undid revision which blanked the article Tag: nowiki added |
||
Line 1:
{{Use dmy dates|date=January 2013}}
'''HTML email''' is the use of a [[subset]] of [[HTML]] (often ill-defined) to provide formatting and [[semantic web|semantic]] markup capabilities in [[email]] that are not available with [[plain text]].
Most graphical [[email client]]s support HTML email, and many default to it.<ref>[http://www.expita.com/nomime.html#programs Configuring thor and Message-ID of a quote. Long [[Uniform Resource Locator|URL]]s can be linked to without being broken into multiple pieces, and text is wrapped to fit the width of the user agent's viewport, instead of uniformly breaking each line at 78 characters (defined in RFC 5322, which was necessary on older [[Data terminal#Text terminals|text terminals]]). It allows in-line inclusion of [[Table (information)|table]]s, as well as diagrams or [[mathematical formula]]e as images, which are otherwise difficult to convey (typically using [[ASCII art]]).
== Adoption ==
Since its conception, a number of people have vocally opposed all HTML email (and even [[MIME]] itself), for a variety of reasons.<ref>[https://subversion.american.edu/aisaac/notes/htmlmail.htm HTML Email: Whenever Possible, Turn It Off!]</ref> The [[ASCII Ribbon Campaign]] is an internet phenomenon advocating that email should continue to be sent in Human Readable [[ASCII]] text format. While still considered inappropriate in many newsgroup postings and mailing lists, its adoption for personal and business mail has only increased over time. Some of those who strongly opposed it when it first came out now see it as mostly harmless.<ref>[http://birdhouse.org/blog/2006/01/15/html-email-the-poll/ HTML Email: The Poll] (Scot Hacker, originator of the much-linked-to ''Why HTML in E-Mail is a Bad Idea'' discusses how his feelings have changed since the 1990s)</ref>
According to surveys by [[online marketing]] companies, adoption of HTML-capable email clients is now nearly universal, with less than 3% reporting that they use text-only clients.<ref name="emaillabs statistics">{{cite web|url=http://www.emaillabs.com/resources/resources_statistics.html |title=Email Marketing Statistics and Metrics |publisher=Emaillabs.com |date= |accessdate=2012-06-24}}</ref> A smaller number, though still the majority, prefer it over plain text.<ref name="clickz data">{{cite web|url=http://www.clickz.com/showPage.html?page=1428551 |title=Real-World Email Client Usage: The Hard Data |publisher=Clickz.com |date= |accessdate=2012-06-24}}{{dead link|date=October 2011}}</ref>
== Compatibility ==
{| class="wikitable" align=right width=50%
|+"Email standards project" ''Acid test'' comparison (as of January 2013)[http://www.email-standards.org/ ]
|-
!Clients !! Result (as of)
|-
|[[Aol webmail|AOL Webmail]]
|{{yes|Solid support (13 July 2011)}}
|-
|[[Apple Inc.|Apple]] [[iPhone]]
|rowspan=3 {{yes|Solid support (13 July 2011)}}
|-
|Apple [[iPad]]
|-
|Apple [[iPod Touch]]
|-
|[[Apple Mail]]
|{{yes|Solid support (28 November 2007)}}
|-
|[[Apple MobileMe]]
|{{yes|Solid support (15 August 2008)}}
|-
|[[Eudora (email client)|Eudora]]<br/>[[Eudora OSE]] codenamed "Penelope"
|{{yes|Solid support (28 November 2007)}}
|-
|[[Microsoft Entourage]]
|{{yes|Solid support (28 November 2007)}}
|-
|[[Mozilla Thunderbird]]
|{{yes|Solid support (28 November 2007)}}
|-
|[[Windows Live Mail]]
|{{yes|Solid support (28 November 2007)}}
|-
|[[Windows Mail]]
|{{yes|Solid support (28 November 2007)}}
|-
|[[Yahoo! Mail]] Beta
|{{yes|Solid support (8 July 2011)}}
|-
|[[Windows Live Hotmail]]
|{{partial|Some improvement recommended (8 July 2011)}}
|-
|[[Google Gmail]]
|{{no|Improvement recommended (13 July 2011)}}
|-
|[[Lotus Notes]] 8
|{{no|Improvement recommended (28 November 2007)}}
|-
|[[Microsoft Outlook]] 2007
|{{no|Improvement recommended (28 November 2007)}}
|}
Email software that complies with RFC 2822 is only required to support plain text, not HTML formatting. Sending HTML formatted emails can therefore lead to problems if the recipient's email client does not support it. In the worst case, the recipient will see the HTML code instead of the intended message.
Among those email clients that do support HTML, some do not render it consistently with [[W3C]] specifications, and many HTML emails are not compliant either, which may cause rendering or delivery problems, especially for users of [[GMail]].
In particular, the <code><nowiki><head></nowiki></code> tag, which is used to house CSS style rules for an entire HTML document, is not well supported, sometimes stripped entirely, causing in-line style declarations to be the [[De facto standard|''de facto'' standard]], even though they are not optimal from a [[Separation of style and content|semantic web]] point of view.<ref>{{cite web|url=http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx |title=Not your ordinary html email tips |publisher=Yourtotalsite.com |date= |accessdate=2012-06-24}}{{Dead link|url=http://web.archive.org/web/20070927043051/http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx |date=February 2009}}</ref> Although workarounds have been developed,<ref>{{cite web|author=Dialect <http://dialect.ca/> |url=http://premailer.dialect.ca/ |title=Premailer: make CSS inline for HTML e-mail |publisher=Premailer.dialect.ca |date= |accessdate=2012-06-24}}</ref> this has caused no shortage of frustration among newsletter developers, spawning the [[grassroots]] [http://www.email-standards.org/ Email Standards Project], which grades email clients on their rendering of an acid test, inspired by those of the [[Web Standards Project]], and lobbies developers to improve their products.<ref>{{cite web|url=http://www.campaignmonitor.com/blog/archives/2007/09/why_we_need_web_standards_supp_1.html |title=Why we need standards support in HTML email |publisher=Campaign Monitor |date= |accessdate=2012-06-24}}</ref> To persuade [[Google]] to improve rendering in [[Gmail]], for instance, they published a video montage of grimacing web developers,<ref>{{cite web|url=http://www.email-standards.org/gmail-appeal |title=The 2008 Gmail Appeal | Email Standards Project |publisher=Email-standards.org |date= |accessdate=2012-06-24}}</ref> resulting in attention from an employee.
== Style ==
Some senders may excessively rely upon large, colorful, or distracting [[font]]s, making messages more difficult to read.<ref>{{cite web|last=Shobe |first=Matt |url=http://www.burningdoor.com/matt/archives/000782.html |title=A pretty fair argument against HTML Email |publisher=Burningdoor.com |date=2004-10-12 |accessdate=2012-06-24}}</ref> For those especially bothered by this formatting, some [[user agent]]s make it possible for the reader to partially override the formatting (for instance, [[Mozilla Thunderbird]] allows specifying a minimum font size); however, these capabilities are not globally available. Further, the difference in optical appearance between the sender and the reader can help to differentiate the author of each section, improving readability.
== Multi-part formats ==
Many email servers are configured to automatically generate a plain text version of a message and send it along with the HTML version, to ensure that it can be read even by text-only [[email client]]s, using the <code>[[MIME content type|Content-Type]]: [[MIME#Alternative|multipart/alternative]]</code>, as specified in RFC 1521.<ref>[http://www.yahoo.com/CIE/RFC/1521/18.htm RFC 1521 7.2.3. The Multipart/alternative subtype]{{dead link|date=June 2012}}</ref><ref>{{cite web|url=http://www.codestone.ltd.uk/software/docs/csmail/tn1010-11-2.pdf |title=TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients. |format=PDF |date= |accessdate=2012-06-24}}</ref><ref>{{cite web|url=http://www.wilsonweb.com/wmt5/html-email-multi.htm |title=Sending HTML and Plain Text E-Mail Simultaneously |publisher=Wilsonweb.com |date=2000-04-28 |accessdate=2012-06-24}}</ref> The message itself is of type <code>multipart/alternative</code>, and contains two parts, the first of type <code>text/plain</code>, which is read by text-only clients, and the second with <code>text/html</code>, which is read by HTML-capable clients. The plain text version may be missing important formatting information, however. (For example, an equation may lose a superscript and take on an entirely new meaning.)
Many{{Citation needed|date=September 2009}} [[Electronic mailing list|mailing list]]s deliberately block HTML email, either stripping out the HTML part to just leave the plain text part or rejecting the entire message.{{Citation needed|date=September 2009}}
== Message size ==
HTML email is larger than plain text. Even if no special formatting is used, there will be the overhead from the tags used in a minimal HTML document, and if formatting is heavily used it may be much higher. Multi-part messages, with duplicate copies of the same content in different formats, increase the size even further. The plain text section of a multi-part message can be retrieved by itself, though, using [[IMAP]]'s FETCH command.<ref>{{cite web|url=http://dsv.su.se/jpalme/ietf/mhtml-discussion.html |title=Do we really want to send web pages in e-mail? |publisher=Dsv.su.se |date= |accessdate=2012-06-24}}</ref>
Although the difference in download time between plain text and mixed message mail (which can be a factor of ten or more) was of concern in the 1990s (when most users were accessing email servers through slow [[modem]]s), on a modern connection the difference is negligible for most people, especially when compared to images, music files, or other common attachments.<ref>[http://momentum.insertdisc.com/archives/2004/09/17/html_email_still_evil_part_1.html HTML Email — Still Evil?]</ref>
== Security vulnerabilities ==
HTML allows for a link to have a different target than the link's text. This can be used in [[phishing]] attacks, in which users are fooled into believing that a link points to the website of an authoritative source (such as a bank), visiting it, and unintentionally revealing personal details (like bank account numbers) to a scammer.
If an email contains [[web bug]]s (inline content from an external server, such as a [[Digital image|picture]]), the server can alert a third party that the email has been opened. This is a potential [[email privacy|privacy]] risk, revealing that an email address is real (so that it can be targeted in the future) and revealing when the message was read. For this reason, some email clients do not load external images until requested to by the user.
During periods of increased network threats, the US Department of Defense converts all incoming HTML email to text email.<ref>[http://www.fcw.com/article97178-12-22-06-Web/ DOD bars use of HTML e-mail, Outlook Web Access]{{dead link|date=June 2012}}{{Dead link|url=http://www.fcw.com/article97178-12-22-06-Web/ DOD bars use of HTML e-mail, Outlook Web Access |date=September 2009}}</ref>
The multipart type is intended to show the same content in different ways, but this is sometimes abused; some [[email spam]] takes advantage of the format to trick [[spam filter]]s into believing that the message is legitimate. They do this by including innocuous content in the text part of the message and putting the spam in the HTML part (that which is displayed to the user).
Most email spam is sent in HTML for these reasons, so spam filters sometimes give higher spam scores to HTML messages.
== See also ==
* [[Enriched text]] — an HTML-like system for email using MIME
* [[MHTML]]
== References ==
{{Reflist|2}}
[[Category:Email]]
[[Category:Internet terminology]]
[[Category:HTML]]
| |||