Content deleted Content added
m Disambiguating links to PGP (link changed to Pretty Good Privacy) using DisamAssist. |
|||
Line 2:
{{Use dmy dates|date=December 2022}}
{{POV|talk=POV|date=December 2021}}
'''HTML email''' is the use of a [[subset]] of [[HTML]] to provide formatting and [[semantic web|semantic]] markup capabilities in [[email]] that are not available with [[plain text]]:<ref>{{Cite web|title = Text Email vs HTML Email – The Pros and Cons {{!}} Thunder Mailer – Mass Emailing Software|url = http://www.thundermailer.com/text-email-vs-html-email-the-pros-and-cons/|website = thundermailer.com|access-date = 2016-01-30}}</ref> Text can be linked without displaying a [[URL]], or breaking long URLs into multiple pieces. Text is wrapped to fit the width of the viewing window, rather than uniformly breaking each line at 78 characters (defined in [https://tools.ietf.org/html/rfc5322 RFC 5322], which was necessary on older [[Data terminal#Text terminals|text terminals]]). It allows in-line inclusion of images, [[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 ==
Line 13:
== Compatibility ==
Email software that complies with [https://tools.ietf.org/html/rfc2822 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.
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 in-line style declarations are inefficient and fail to take good advantage of HTML's ability to [[Separation of content and presentation|separate style from content]].{{citation needed|date=January 2015}} 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 |accessdate=2012-06-24}}</ref> this has caused no shortage of frustration among newsletter developers, spawning the [[grassroots]] 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. 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 |accessdate=2012-06-24 |url-status=dead |archiveurl=https://web.archive.org/web/20120515030536/http://www.email-standards.org/gmail-appeal |archivedate=15 May 2012 }}</ref> resulting in attention from an employee.
{| class="wikitable"
|+"Email standards project" ''Acid test'' comparison (as of January 2013)[http://www.email-standards.org/
|-
!Clients !! Result (as of)
Line 77:
== 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 [https://tools.ietf.org/html/rfc1521 RFC 1521].<ref>[http://tools.ietf.org/html/rfc1521#section-7.2.3 RFC 1521 7.2.3. The Multipart/alternative subtype]</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. |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, a mathematical 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}}
| |||