Talk:HTML email

Missing: Origins of HTML email[edit]

The article doesn't seem to mention who introduced HTML E-mail. I've heard it was Microsoft but I hope someone that knows more details would add that information to the article. Thank you!
79.134.123.82 (talk) 10:43, 21 December 2009 (UTC)[reply]

Lots of things are attributed to Microsoft without good reason. If you go to the specifications, RFC 1049 (1988) listed Postscript, SCRIBE, SGML TeX and troff. The first MIME RFC, RFC 1341 (1992) just specified text/plain and text/richtext. The latter was some SGML bastard and (it seems to me) weakly defined. RFC 2045 and friends (1996) don't seem to mention HTML either, but provide ways to register new types, such as text/html.

And there I ran out of time. But I agree: who introduced it and where, if anywhere, it was standardized – that should be in the article. JöG (talk) 08:50, 20 March 2010 (UTC)[reply]

According to Jamie Zawinski in the blog post jwz: "HTML email, was that your fault?", he can’t find any mail reader that was able to display HTML messages before Netscape 2.0, which he worked on. Jamie also details specific milestones in support for HTML in various mail clients. The email that he quoted himself sending ends, “It would be fantastic if you could update http://en.wikipedia.org/wiki/HTML_email with your findings.”
—Rory O'Kane (talk) 03:58, 21 September 2017 (UTC)[reply]

I agree, but I can't find a source. I was sure that I used html in e-mail no less than 20 years ago, so the Netscape 2.0 knowledge definitely supports that. Though I don't remember using Netscape, I remember using AOL, and first using html within that service, and then switching to webbased Hotmail and then gmail for the majority of my email use. 174.79.102.68 (talk) 15:57, 19 April 2019 (UTC) Sam[reply]

Languages[edit]

I'm not too familiar with foreign language encodings and such, but apparently. using HTML to encode languages like Japanese is easier and preferred, though I imagine there is a way to send non-ASCII in the original plain text specs? — Omegatron 13:12, 15 September 2006 (UTC)[reply]

Quoting, implementation[edit]

It should explain how quoting is often ruined by the fixed width of text/plain, like:

> > First message here and it g
oes
> > on to the next line and the
n
> > goes onto the next line, to
o.

> Then a reply is here and it 
> goes onto the next line and 
> then goes onto the next line,
> too.

Then another reply here and 
going onto the next line and 
another line here.

and how HTML handles this with blockquote tags and regular wrapping text. I can't find the conventions or standards behind plain text email, but it seems that the 78 character horizontal limit was set by RFC 2822, to ensure that plain text shows up the same way on different terminals. I have seen a number of other limits proposed, though, from 60 to 80 characters, so I don't know if there are fights about this, too, or what. I assume that they allow for the addition of some quoting > signs, but probably also assume that the writer will be "netiquettely" and only quote the last message. Of course this is a wild assumption, in emails this is not the case, and often on newsgroups, so we get the bad wrapping thing. Also screws up ASCII art, etc. HTML Threading: Conventions for use of HTML in email discusses using semantic blockquote markup to indicate the author of each snippet of text, so that email clients can display email threads efficiently. I have a feeling gmail takes advantage of this for conversation view, but maybe not.

Using HTML in E-mail explains some of the technical aspects of how messages with inline content are coded, which we should include. — Omegatron 04:45, 16 September 2006 (UTC)[reply]

Also, I know that seeing the crazy formatting that some people use helps me to identify the type of person they are, and avoid buying things from them, for instance. We'd need to find a reference of someone saying something similar, though, to include it. — Omegatron 05:02, 16 September 2006 (UTC)[reply]

This is why we have format=flowed (in the Content-Type header), and editors which understand email/news quoting. It's a poor editor which just hard-wraps like that, or at spaces, without at least inserting the correct indentation. Dsalt (talk) 22:51, 29 March 2011 (UTC)[reply]

Standardization[edit]

Has anyone attempted to standardize the features and markup? Clearly it hasn't been standardized, but were there any attempts? — Omegatron 18:27, 23 July 2007 (UTC)[reply]

HTML Email and Outlook 2007[edit]

I'm no expert, but this article implies there might be a problem with the rendering of HTML email in the upcoming new release of Outlook. Might someone want to add something about this? - 10:46, 26 July 2007 (GMT)

I would imagine there are problems with rendering of HTML email in all releases of Outlook. — Omegatron 23:45, 26 July 2007 (UTC)[reply]

Outlook 2007 & 2010 use Microsoft Word's 'unique' HTML rendering engine. Outlook 2003 used Internet Explorer's. 01:47, 18 August 2010 (GMT) —Preceding unsigned comment added by 213.107.233.169 (talk)

html email madness![edit]

Why is it in the last year all the sudden many automated emailers are sending all html emails not even with multipart and thus no plain text area above the html? Not only is it desirable to not render html for security reasons, but bandwidth requirements on mobile devices, etc., I also like plain text for simplicity. I see many of these emails are just using the default font/color/size anyway so what's the point? 66.114.93.6 (talk) 00:07, 3 October 2009 (UTC)[reply]

HTML e-mail was a bad idea to begin with, but the later years it has grown significantly worse. Earlier it was at at least possible to read them with little difficulty, only having an "img src=" here and an "a href=" there. Nowadays it seems like every corporation is using the same broken package formatting it all as a "table" where the actual text is buried in 100x as much code, wasting kB's on formatting the text of empty cells, encoded as quote=3D-unrea=3Dable and where everything pretends to be !important. Bonus points if the whole garbage is binary-encoded to make sure it looks like spam. Considering how it only appeals to advertisers, spammers and other corporate users (probably the same who until recently routinely sent out .doc attachment mails), I see no reason we should tolerate this nonsense. — Preceding unsigned comment added by 85.166.186.36 (talk) 05:39, 6 March 2019 (UTC)[reply]

POV[edit]

The article is subtly biased in favor of HTML in mail.

The intro only mentions a long list benefits, and none of the drawbacks
The adoption section uses weasel wording to make opponents look like extremists: they are vocal and reject even MIME.
In the remaining sections there is, I think, a tendency to downplay the negative aspects; to mention it but explaining why it is (no longer) relevant.

JöG (talk) 09:07, 20 March 2010 (UTC)[reply]

Be bold. --MZMcBride (talk) 19:38, 16 May 2013 (UTC)[reply]

@Jgrahn:, I agree. Except that I don't think it is subtle; there is not even a corresponding plaintext email article, as of this writing. I tried to start one earlier this year, but it got moved to draftspace and forgotten about. There seems to be more effort to undo partial contributions than to fix the minor problems with those contributions; thus inhibiting the wiki philosophy of many small contributions accumulating to form complete articles. As well as there being altogether no article for plaintext email yet, this article is biased towards advantages and support, as you point out. E.g., mentioning that “Most graphical email clients support HTML email, and many default to it.”, without mentioning that most if not all CLI and TUI clients default to plaintext and don't support HTML, and some GUI clients still deliberately default to plaintext despite continuing to be actively maintained. I happen to use one such GUI client called Claws Mail, a very lightweight client (for a GUI) which does not have support for writing HTML email. I asked the developer about this and their reply was that it is deliberate. HTML email doesn't really make sense for lightweight software, especially for TUI and CLI clients. It's not a matter of old replacing new; there are new versions of lightweight email clients which have perfectly good reasons for refusing to support the software bloat of HTML email, and indeed, occasionally there are completely new email clients that default to plaintext. In fact, I think actually most major TUI email clients' initial releases have been since HTML email has been around; Elm, Pine, and Mutt are the only exceptions that I can think of. This article does not reflect that there is a whole community that is refusing HTML email, not for being ‘out-of-date’ but for energy efficiency, code simplicity, to avoid remote content phishing/tracking, or various other reasons. While I do know a lot about this subject, I do not feel that I have the expertise necessary to single-handedly balance the POV of this article, or to write the plaintext email article in full. Therefore, I have added a {{POV}} banner box at the top of this article to call for help. —James R. Haigh (talk) 2021-12-07Tue03:14:17Z

Draft:Plaintext email has now been deleted; plaintext email article still nonexistant!! Wikipedia has become so very ‘deletionist’ in recent years. :-( The easiest way to fix problems is to delete them, it seems. Okay then, perhaps the best way to fix the NPOV violation is to delete HTML email too, then that way it's neutral, right? Is that the way we do things on Wikipedia these days? —James R. Haigh (talk) 2021-12-12Sun15:53:11Z

Accessibility[edit]

This article needs a section on the accessibility of HTML email. See [1] for example of a good source. Thryduulf (talk) 11:07, 16 May 2013 (UTC)[reply]

While not a reliable source, mailarchive:wikimedia-l/2011-April/112038.html explains why the accessibility concerns are largely (if not wholly) overblown these days. --MZMcBride (talk) 19:36, 16 May 2013 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on HTML email. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

Attempted to fix sourcing for http://www.asciiribbon.org/
Attempted to fix sourcing for http://www.emaillabs.com/tools/email-marketing-statistics.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 07:13, 28 March 2016 (UTC)[reply]

Removed reference re: gmail being especially bad w/ HTML email[edit]

Hope folks agree with this. The reference was marked as needing citation and was out of date. The comment was from 2015, and in 2016 gmail started to support inline CSS and media queries, making the statement here inaccurate/out of date. Reference heading 'GMAIL SUPPORT FOR INLINE CSS AND MEDIA QUERIES' part way down on this post for info on the changes of Sept 2016 that make the comment I removed obsolete: https://www.smashingmagazine.com/2017/01/introduction-building-sending-html-email-for-web-developers/

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on HTML email. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:07, 27 October 2017 (UTC)[reply]

Web bugs[edit]

> For this reason, all modern popular email clients (as of year-2019) do not load external images until requested to by the user.

Unfortunately, Gmail loads external images by default (and has for a while, IIRC). Not sure how to rephrase / change that sentence.

--164.116.112.36 (talk) 08:59, 27 August 2020 (UTC) teal[reply]