[HN Gopher] Use plain-text email
___________________________________________________________________
Use plain-text email
Author : lproven
Score : 194 points
Date : 2022-09-12 14:09 UTC (8 hours ago)
(HTM) web link (useplaintext.email)
(TXT) w3m dump (useplaintext.email)
| jaytaylor wrote:
| Years ago I made a Go library called `html2text' just for this:
|
| https://github.com/jaytaylor/html2text/
|
| https://jaytaylor.com/html2text
|
| It takes HTML as input and generates markdown-esque plaintext,
| with the main focus being to make the plaintext version easy and
| pleasant to read for human beings. Then using MIME types*, you
| transmit both the rich html version alongside the generated
| text/plain version.
|
| This is cool because it makes it easy to respect both rich
| clients (like Gmail et. al.) as well as command-line or other
| clients which work better with simple text.
|
| Hope this helps folks have the best of both worlds! :) cheers
|
| * n.b. To ensure this works properly, be sure to use the right
| MIME headers:
|
| https://stackoverflow.com/questions/3902455/mail-multipart-a...
| joshmanders wrote:
| Yep, I do similar with all emails I send, run the html through
| a `html2text` transformer and attach that as the plaintext
| variant of the email.
|
| Now whatever the receiver decides they want to view they can.
| jacobsenscott wrote:
| Don't. Your plain text email is going to render like shit in any
| modern mail client, and you are going to look like fool who can't
| write an email.
|
| You should actually try this if you use plain text email - email
| yourself and try and read it in a normal mail client (gmail,
| outlook, etc) on a phone. You'll need to scroll horizontally to
| read the message.
|
| Now read it on a normal desktop email client. You'll see a skinny
| tall column of text in a tiny font.
|
| Now reply to a normal html email thread and view it in a normal
| mail client. Congrats - you've just broken the formatting for
| _everyone* on the thread. Nobody wants you see those >> things
| all over the place.
|
| I don't know why this idea persists. Nobody wants to read a book
| in a fixed width font, nobody wants to read a web page in a fixed
| width font that doesn't adapt to your viewport size, etc. Hell,
| programmers even want colors and fancy formatting in their source
| code.
|
| Plain text email is the ham radio of the internet. If you are an
| email hobbiest and you enjoy sending and receiving plain text
| emails to other hobbiests more power to you. But don't try and
| setup a meeting at work over your ham radio. You'll just look
| dumb._
| JohnFen wrote:
| > You should actually try this if you use plain text email -
| email yourself and try and read it in a normal mail client
| (gmail, outlook, etc) on a phone. You'll need to scroll
| horizontally to read the message.
|
| OK, I just did. I didn't have any of those issues at all.
| Perhaps it depends on the exact mail client you use?
| swyx wrote:
| Quincy Larson runs a 4 million subscriber list with plain text
| email https://www.freecodecamp.org/news/quincy-larson-5-links-
| wort...
| segaboy81 wrote:
| I had a BSD-geek friend whose area of specialty was in deploying
| and maintaining mail servers on that platform. He had always been
| an advocate for plain-text emails. He was also a single guy who
| had sex with his dog, so he wasn't emailing pictures to his
| grandma.
|
| Personally, I think evolving email into HTML has always been a
| foregone conclusion regardless of the inconvenience it causes to
| an extreme minority. Plus, I like the convenience of sending
| photos to grandma and checking her email is all she has the
| aptitude for anyway.
|
| Long live HTML mail!
| slaymaker1907 wrote:
| I really hope you meant "sex like a dog" or something with that
| anecdote.
| lbriner wrote:
| "HTML emails are mainly used for marketing - that is, emails you
| probably don't want to see in the first place."
|
| Stops reading.
| marginalia_nu wrote:
| To be fair, I can't think of the last time a human sent me an
| HTML email.
| remram wrote:
| You mean HTML-only email?
| marginalia_nu wrote:
| No, an email that wasn't text/plain.
| remram wrote:
| With multipart, every part has a separate mimetype. Your
| client will decide which one to show.
| https://en.m.wikipedia.org/wiki/MIME#Multipart_messages
|
| Do you mean that there is a part that isn't text/plain
| ("HTML email") or that there is no part that is
| text/plain ("HTML-only email")?
| marginalia_nu wrote:
| I mean there is no HTML part.
| steviedotboston wrote:
| This ship sailed a very long time ago.
| sbuk wrote:
| No.
| sbuk wrote:
| I don't see the need to write why I'm saying no. There are over
| 1000 words in an article that says nothing. This is someone
| that is pissed off because they basically want to use email
| like it was 1979.
| joemi wrote:
| I don't necessarily agree with the article (and I don't see
| it ever being possible to get the world to move back to
| plaintext email), but the article isn't saying nothing. There
| are legitimate reasons to want plaintext email. I wouldn't
| dismiss it in the way you've done. We (HN community) can and
| should have better discussions than this.
| Bakary wrote:
| HTML is great when you deal with lots of email correspondence at
| work. The signatures and formatting make it easier to anchor
| memories and navigate conversations.
| queuebert wrote:
| Even text email clients can organize messages into threads,
| which arguably is much clearer than a long HTML email with
| nested, multi-colored replies.
| naet wrote:
| The real problem with HTML emails is inconsistent rendering by
| different email clients. I had to make some HTML email templates
| for a marketing campaign, thought it would be easy seeing as I
| make HTML website template all day.... ended up spending hours
| debugging random Microsoft Outlook rendering inconsistencies and
| other client issues.
|
| Some clients don't support anything but inline styles, others
| support style tags. Some support media queries, some don't. Some
| support custom fonts / web fonts, some don't. Gmail in browser
| behaves differently from Gmail android client behaves differently
| from Gmail iOS client, etc. There's an absolutely infuriating
| dark mode on Outlook that randomly swaps certain color hues and
| as far as I can tell there's no way to detect or show different
| styles for it, you just have to make your design stand up to
| certain colors being swapped (don't use any logo or other image
| that can't stand clearly against both black and white
| backgrounds). I learned a lot about a bunch of extremely legacy
| HTML and CSS rules that would never be used in a modern website
| but were basically required for a semi-responsive email.
|
| I won't ever do it again- if I need a custom styled email, I'll
| use someone else's template or email template builder service.
| mxuribe wrote:
| Thanksfully, you are not alone, and lots of these cuts have
| been codified into best practices...and published as guides by
| the big players in the email marketing world (e.g. mailchimp,
| campaign monitor, etc.). If/Whenever you need to work in this
| area, just look up one of those guides from those established
| players and follow their lead...better yet, grab one of their
| templates when they offer them. In addition, as @cygned has
| noted, there are even some "meta languages" (like MJML and many
| others) created by these same big email providers that serve to
| do away with some of the more annoying parts of crafting email
| templates. Of course, i hope to never have to spend too muich
| time in creating templates for email....just too many
| nightmares from so many yearsplaying in this space! ;-)
| cygned wrote:
| Try MJML, works wonders
| cjf101 wrote:
| I'm definitely a bit of a curmudgeon when it comes to email.
| Email is about communication and html gives people tools that
| they mostly use to make communication harder, not easier. For me,
| I prefer plain text email when I can get it. The main issue for
| me is that most of the uses of html email I see simply do not
| increase the utility of the email from the reader's perspective.
|
| Large signatures don't communicate anything useful to me that
| isn't in the email header. The phone number can be nice, but you
| didn't need html for that. Your brand identity that takes up half
| a page (more since I keep email in a small window to the side of
| my monitor) does nothing other than obscure the content of the
| email. Trust me, sending me an intensely formatted email with
| lots of pictures does not increase the likelihood of me doing
| business with you.
|
| 99% of email I receive contains < 1 paragraph of useful
| information. I would prefer if people just sent that. Then I can
| read it quickly (since it uses the same font as everything else,
| not that faux handwriting font you found somewhere and thought
| looked great) and respond quickly and helpfully, which I hope was
| the purpose you sent the email in the first place.
|
| There's probably a 1% where a nicely formatted document with
| graphs and images and headers are helpful. But you can just
| attach a document to the email if you're going to put that kind
| of effort it.
| Existenceblinks wrote:
| As someone who invented email DSL in org that did heavy email
| marketing, yes, please use plain-text, save dev time 500 hours a
| year. Generated image from html is also doable. When user click
| image link in email, it goes to that html page.
| mattl wrote:
| Which developer is being saved 500 hours a year?
| Existenceblinks wrote:
| Anyone that's responsible for implementing email layout from
| marketing team's mockups.
|
| Marketing: lets try this new fancy widget floating on the
| left and that on the right, make it look good for Outlook
| v.xxx+ on android urghhh.
| jeffrom wrote:
| Fun bit of history: Jamie Zawinski thinks he may have invented
| html email while at Netscape [0].
|
| [0] https://www.jwz.org/blog/2017/09/html-email-was-that-your-
| fa...
| robin_reala wrote:
| It might be worth pointing out that JWZ doesn't like HN and
| redirects any referrals to an interesting image, in case you
| were thinking of clicking on that directly instead of copying
| and pasting.
| colejohnson66 wrote:
| Maybe @dang should just change it so links to jwz.org aren't
| clickable? It would force us to copy-paste.
| Cyberdog wrote:
| Why is it HN's job to fix someone else's breakage of the
| web's standard behavior?
| colejohnson66 wrote:
| It's not. But that doesn't mean we can't try to avoid the
| issue. For example, stores aren't required to use time
| delay safes (and other robbing counter-measures). After
| all, robbery is illegal, but they still probably _should_
| install them.
| mycoborea wrote:
| I do wish more email clients could render markdown from a
| plaintext message (written with markdown syntax, of course).
| JonathanBuchh wrote:
| I've been using MailMate[1] on MacOS, but I don't know any
| other email clients that render Markdown.
|
| [1]: https://freron.com/
| DavideNL wrote:
| Thanks for the tip, looks great i will definitely give it a
| try.
|
| For EUR62, i wonder how often a new version arrives / i'll
| have to buy/upgrade again...
| Mailtemi wrote:
| My email app _Mailtemi_ actually does HTML -> Markdown. Still
| curious, is it worth going this direction?
|
| I'm using Markdown for email preview, local search, etc. In
| the future I think about experimenting with voice mail.
| Something like "Read all important emails", which will skip
| all marketing, updates, or forums. Also I have an
| experimental feature email to be viewed always in Markdown.
| JohnFen wrote:
| I'd be extremely happy if markdown were the accepted way of
| applying formatting. It lacks almost all of the problems with
| formatting emails with HTML.
| asoneth wrote:
| Agreed. Every time I've tried to switch to using plain text I
| always encountered cases where additional formatting made my
| message easier to read and understand.
|
| I'd be perfectly happy with Markdown or likely RFC 1896 as
| someone else mentioned.
| lproven wrote:
| Formatted text is less accessible. Accessibility is a legal
| requirement in many countries; in the UK it has been a legal
| requirement for _twelve years_.
|
| https://info.webusability.co.uk/blog/what-is-the-law-on-
| acce...
|
| Formatted email is especially difficult for blind users,
| whether they are using a screen reader or a Braille display.
|
| Formatting can't be read aloud via text-to-speech if a
| sighted person is using it on a smartwatch or similar.
|
| Formatting does not survive automatic translation. I live in
| a country where I do not speak the local language and I rely
| very heavily on machine translation; in fact in the last 5min
| I have just paid my gas bill using Google Translate to
| understand the email I was sent, and then again to navigate
| the gas supplier's website.
|
| Formatting does not display in on-screen notification
| messages, and it may not survive being forwarded, read in
| certain clients, etc.
|
| If you find you are relying on it, then you should improve
| your writing skills, because you are unwittingly excluding
| people and some will receive damaged versions of your emails
| which they can't understand correctly.
| asoneth wrote:
| > Formatted text is less accessible.
|
| Is this universally true? I'm not an accessibility expert
| but from working on a couple 508 projects it seems that
| formatting such as headings improves accessibility and
| makes navigation easier.
|
| > If you find you are relying on it, then you should
| improve your writing skills
|
| Some of the content I email includes screenshots of issues,
| photographs from studies, iconography, and data
| visualizations. Beyond ensuring that I include
| accompanying/alternate text I accept that these will not be
| accessible.
|
| Other content includes hierarchical lists and snippets of
| tabular data. While these can be creatively emulated using
| plain text I find that people doing so typically resort to
| a jarring sort of ASCII-art approach that ends up being
| even less accessible than just using the proper semantic
| tags or markdown.
|
| More broadly I find it disappointing that we ended up in
| this situation where technical constraints dictate what is
| good writing. Italics has been part of writing for hundreds
| of years and now it's relegated to "markup" because of
| decisions some computer engineers made sixty years ago. Can
| you imagine if the ASCII standard had stuck with the
| initial all-caps specification and relegated lowercase
| letters to be markup? Would we now be arguing that people
| who don't write in all caps "should improve [their] writing
| skills"?
|
| Personally I prefer _structured_ text to either plain or
| formatted text. Formats like markdown aren 't perfect but
| they basically provide what I need so it's disappointing
| that email clients force us to choose between the extremes
| of plain text and HTML.
| lproven wrote:
| Mozilla Thunderbird does that, with the older, pre-Markdown,
| internet-standard version.
|
| Which also works in Facebook Messenger and in WhatsApp, which
| very few people seem to know.
| jrnichols wrote:
| until you eradicate the likes of Outlook and Gmail from the
| internet, I think this is pretty much a lost cause.
| lproven wrote:
| Gmail works in plain text just fine. Bottom-quoting,
| everything.
|
| I have it configured to plain-text by default.
|
| If you're going to blame webmail, then blame the crappy broken
| webmail clients: Hotmail, Yahoo, AOL, etc.
|
| But not Gmail. Its good plain-text handling is one of the
| reasons I use it.
| itslennysfault wrote:
| > HTML emails are mainly used for marketing
|
| Whaaaaat? How about a more honest version...
|
| > HTML emails are mainly used _BY LITERALLY EVERYONE_
| JohnFen wrote:
| Not true. 90% of the emails I get from real people are plain-
| text. 100% of the emails I get from businesses are HTML. It
| makes it quick and easy to sort out a lot of the garbage.
| moxieta wrote:
| bombcar wrote:
| This is the true answer, everyone uses them and that battle has
| been lost years and years ago.
|
| The effort should be fought in adding a _newer_ way of doing
| HTML email that is better, and finally kill that damn IE
| 6-based renderer used by Outlook. Curse that thing.
| UberFly wrote:
| Yes, this. Also, any good email client will strip out the
| graphics and just give you formatted text anyway. I use
| Fastmail's web interface and there's a "Load Images" button but
| I rarely click it. Best of both worlds.
| boffinism wrote:
| "[Plain-text email] is strongly preferred"
|
| I think it's significant that this is written in the passive
| voice. Because written this way it has the semblance of
| officialness, of generalness. Whereas writing it in the active
| voice would reveal that the people doing the preferring are just
| the people who made this website, and this preference is just
| that: a preference.
|
| I love HTML emails, because I use italics basically all the time
| in my writing, and underscores _just don't offer the same
| experience_.
| wrs wrote:
| There is a standard text/enriched content type that enables
| only "text formatting" and not arbitrary HTML. But HTML rapidly
| took over email, and now I don't know what clients even
| implement text/enriched anymore.
|
| https://www.rfc-editor.org/rfc/rfc1896
| [deleted]
| soheil wrote:
| This. It's interesting that there is nothing about the authors
| mentioned anywhere except:
|
| > "Plaintext Certified" graphic by Jens
| bdn_ wrote:
| Right above that line, the site notes that the code is
| available here [1]. It looks like the majority of it was
| written by Drew DeVault, who runs SourceHut [2], where the
| code is hosted.
|
| [1]: https://git.sr.ht/~sircmpwn/useplaintext.email
|
| [2]: https://sourcehut.org
| stjohnswarts wrote:
| Yeah I used to be a text fanatic and then started seeing the
| value in making things stand out in HTML. Lol, some co-workers
| just don't get things that aren't in bold or well-formed
| bullets. I rarely put in images, but when I do having them
| inlined is indeed valuable. I just wish we had a proper subset,
| though. Maybe markdown would have been way better if it was
| around and well known at the time.
| petercooper wrote:
| In normal text (i.e not Markdown), using /slashes/ can get the
| idea across more visually. I think I picked it up on Usenet
| where it was reasonably common.
| rudyon wrote:
| Slashes have the problem of being notation used for the IPA.
| So if you dabble in linguistics like I do. That might be a
| problem.
| wjsetzer wrote:
| Since IPA uses a lot of unicode characters, would it be
| that much of a problem? IPA, imo, usually has a very
| specific look to it that wouldn't be confused with "normal"
| text.
| frenchy wrote:
| It wouldn't be _that_ much of a problem, but I think
| there 's enough room for confusion, that I think people
| just wouldn't bother with it. For example, while it would
| be obvious that /tith/ is "teeth", something like /bad/
| could be "bad" emphasized, or "bod". It wouldn't be that
| hard to disambiguate, but it is a little extra strain on
| the reader.
|
| Most of the time, italics aren't actually all that
| important though, and could easily be replaced with other
| linguistic features.
|
| Edit, another thing is that the slashes is actually
| graphemic notation, not phonetic. There's no reason that
| you have to use something modeled off the IPA there, it's
| just common to do so. You could use any alphabet.
| [deleted]
| rustyminnow wrote:
| What is "the IPA"? Is that "the International Phonetic
| Alphabet"? https://en.wikipedia.org/wiki/International_Phon
| etic_Alphabe...
| [deleted]
| lcnPylGDnU4H9OF wrote:
| That would be my wager. In particular, it seems they're
| talking about the / ... / notation described in the first
| table here: https://en.wikipedia.org/wiki/International_P
| honetic_Alphabe...
| quasarj wrote:
| arkitaip wrote:
| Italics have been part of literature for hundreds of years,
| pretty sure you can manage to read an email or two with
| italics in them.
| rhplus wrote:
| Italics have also been part of Hackernews for _gosh knows
| how long_...
| [deleted]
| memorable wrote:
| Or at least read them without the italics.
| [deleted]
| scblock wrote:
| No.
| etchalon wrote:
| HTML in email was a deeply horrible idea with no justification
| beyond "Well, Microsoft wanted to make some emails prettier..."
| [deleted]
| upofadown wrote:
| In the middle of an entirely different discussion[1] it more or
| less fell out that the problems associated with HTML emails would
| not be problems if we started treating unsigned/anonymous emails
| with some reasonable amount of suspicion. Letting any rando on
| the internet have access to your HTML interpreter doesn't seem
| reasonable and things are much better if you only allow that
| access to people you actually know.
|
| HTML is not the only problem with email that would be lessened if
| we could finally get people to start signing their emails and
| start treating anonymous emails with suspicion...
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:no_new_ae (See the
| "A proposed alternative solution to EFAIL" section)
| stjohnswarts wrote:
| Can you cite any major security breaches accomplished by HTML
| in email context? I'm talking HTML and not links. I think links
| should be banned in email, and you should be forced to copy and
| paste them to get to wherever you're going, it's too easy to
| hide the actual link with hypertext.
| [deleted]
| nailer wrote:
| Plain text email with hard line wrapping looks awful on most
| devices except terminals.
| gerikson wrote:
| Previous discussion (341 comments):
|
| https://news.ycombinator.com/item?id=20513987
| etchalon wrote:
| The primary argument I'm seeing against Plain Text Email is "But
| I like formatting!"
|
| OK.
|
| But there were probably better ways to achieve lightweight
| formatting options that didn't include "Let's embed a full web
| browser in our email client."
| russfink wrote:
| There is no rationale given as to "why plaintext." HTML can be
| much more expressive in a shorter amount of authoring time.
| remram wrote:
| There is, it's further down the page:
| https://useplaintext.email/#why-plaintext
| vel0city wrote:
| > Rich text isn't that great, anyway
|
| _proceeds to write a nearly 3,000 word document with rich
| formatting an inline images..._
| eatonphil wrote:
| Sure there is: https://useplaintext.email/#why-plaintext. (I
| don't agree with it, but it's there.)
| jwithington wrote:
| If I'm not phishing or tracking anyone as the sender, those
| points aren't applicable. If I am, I'm going to use HTML anyway.
|
| if you are using an email client that only supports plain-text,
| we're probably already in some Matrix.org chatroom together or
| following each other on Mastodon and I'll just hit you up there.
| yyyk wrote:
| Plain text is plainly unusable for a significant amount of
| people. Mobile? Have fun with a small font size to accommodate 80
| chars. Ultra-wide? Same flowing problems. Right to Left language?
| Learn to 'work' with zero-width characters or you're SOL. Want to
| give more data to screen readers (sometimes the table is actually
| a table)? Hah.
|
| Some people need to understand there are more use cases to email
| than mailing lists and that the 90s aren't coming back.
| discreditable wrote:
| 80 char wrapping is solved by format=flowed. However none of
| the popular providers seem to implement it.
| adolph wrote:
| Yes, a lot of the "problems" of plain text boil down to poor
| authoring/rendering tools.
|
| On the other hand, humanity would probably be better served
| by moving toward semantic representation instead of fiddling
| in the deck over txt vs html.
| tadfisher wrote:
| Changing the content type to include format=flowed means
| you're not sending plain text anymore. The content is some
| lightweight markup that's compatible with renderers that only
| understand plain text. This may seem pedantic, but it leads
| to real-world usability issues when folks with noncompliant
| MUAs quote or forward your flowed email; noncompliant meaning
| compliant with every standard except the one RFC that
| introduces format=flowed that isn't linked by the other RFCs
| one follows when writing an MUA, which makes sense since this
| is a one-off hack introduced by Eudora engineers and
| haphazardly implemented by some desktop clients.
|
| In short, I completely agree with you.
| upofadown wrote:
| If your display device can't even handle 80 column monospaced
| text then you need another display device.
|
| There is nothing special about a smart phone that should
| prevent the display of the most basic format there is. The
| problem is with the email client...
| ThePowerOfFuet wrote:
| > Mobile? Have fun with a small font size to accommodate 80
| chars.
|
| Whoever said the column width has to be 80 chars everywhere?
| yyyk wrote:
| Not uncommonly, the provider/program through which the email
| was sent.
| ThePowerOfFuet wrote:
| Then it will just contain extra line breaks, but the mobile
| MUA reading it will reflow it just fine.
| couchand wrote:
| It's really amusing how people addicted to rich text assume
| plain text suffers the same limitations.
| teddyh wrote:
| I'll settle for text/enriched (RFC 1896). It's the best of both
| worlds: The safety of plain text, but proportional fonts, flowing
| paragraphs, and text styling like HTML.
| thomashabets2 wrote:
| Partly the reason I wrote and use this command line client for
| GMail: https://github.com/ThomasHabets/cmdg
| acidburnNSA wrote:
| Honestly if the default font for composing and reading was better
| I'm sure I'd like the look and feel of plaintext much more.
| Surely it's a setting somewhere, I just haven't gone looking for
| it.
| zahllos wrote:
| In thunderbird you can do this quite easily.
| Edit|Settings|Fonts&Colors|Advanced. You can pick your default
| fonts for sans, serif etc and decide if plaintext should use a
| monospaced font or not.
|
| I think most mail clients can do this, but thunderbird is what
| I use. On Windows, preferences may be under Tools instead. No
| idea on Mac.
| dimensionc132 wrote:
| Plain text is preferred always; no pixel tracking
| yonrg wrote:
| I'm a huge proponent of text/plain.
|
| There was a long-ish thread on the mutt mailing list recently,
| which open my narrow mind a bit. Html formatted mails are not a
| question of personal preference. Exchanging Mails with other
| people also includes supporting their way of dealing with mails.
|
| So since a long time I convert text/html to plain text in order
| to be able to read that. Since recently, I also send a simple
| multipart mail with both text/plain and text/html. The conversion
| script it a simple 10 lines python markdown script. All done and
| all happy.
|
| In particular, it makes my mail more readable on any kind of
| display; e.g. narrow phone or wide monitor.
|
| I'm still happy to converse only via text/plain, like here.
| jabroni_salad wrote:
| I'm willing to wiggle a bit here. Stop putting pictures and fixed
| width tables in your signatures at least...
| mxuribe wrote:
| > ...Stop putting pictures and fixed width tables in your
| signatures at least...
|
| This is what i think of whenever i change employers, and/or
| they rebrand and need "everyone to come on and let's all update
| our email sigs together to support the brand!" ugh!
| Eric_WVGG wrote:
| I love fangless manifestos like this, because they're usually
| right, and there's nothing better than a quixotic crusade. Here's
| the hill I'll die on: email works best when it's like a long-form
| SMS message.
|
| As for the folks who go on about branded marketing emails...
| gawd, it's like hearing someone say "actually I wish I got more,
| better junk mail"
|
| It's a pity that something like Markdown didn't exist back in the
| nineties. If we could just have had some really basic formatting
| options (bold, italics, and a couple images are not unreasonable
| requests), the whole scourge of HTML email might have been
| sidestepped.
| hammyhavoc wrote:
| Are there any other manifestos that you are particularly fond
| of?
|
| I hear ya on Markdown.
| ChrisArchitect wrote:
| Discussion from 3 years ago:
| https://news.ycombinator.com/item?id=20513987
| burnte wrote:
| No, it's 2022.
| JohnFen wrote:
| I never allow HTML to render in my emails, for security purposes.
|
| I've found it to be rather helpful in determining which emails to
| delete immediately. If it's HTML, it's probably commercial in
| nature, and if I can't easily read the contents in the HTML
| source, then it's certainly an email that isn't worth reading at
| all.
|
| That said, email in general would be greatly improved if it were
| strictly plain-text.
| cube00 wrote:
| Some companies have given up on plain text completely. I'm
| getting these kind of messages now:
|
| _We have tried to send you this email as HTML (pictures and
| words) but it wasn 't possible. In order for you to see what we
| had hoped to show you please click here to view online in your
| browser:
|
| <long-url-with-lots-of-tracking-guids>_
|
| Ironically in this case the HTML message they so dearly hoped I'd
| see is only a notification that there is an update and I should
| go to the website and login to see what the update is. To top it
| off, the only picture in the message is the company's logo.
| dmitriid wrote:
| > Some companies have given up on plain text completely. I'm
| getting these kind of messages now
|
| To make maters worse, there's now AMP for email,
| https://amp.dev/about/email/
| Existenceblinks wrote:
| This is the way. When I got an newsletter email, I quick scan
| for its blog link immediately and go to read it on website.
| superkuh wrote:
| The worst part of those is that most of the time the HTML isn't
| even HTML. It's encoded in some some sort of weird email-html-
| specific content type. Base64 if you're _lucky_. Something far
| more obscure and email-html specific if you not.
|
| When that happens I then have to copy the raw encoded "text"
| into some shady website $email-html-specific-content-type to
| text converter just to get the html in it's natural character
| set to manually find and copy the <long-url-with-lots-of-
| tracking-guids>.
| blueflow wrote:
| Do you mean https://en.wikipedia.org/wiki/Quoted-printable ?
| Since its a transfer encoding, the email client needs to
| decode it before rendering it. Its comparable to HTTP
| chunking.
| superkuh wrote:
| Ah, so not directly HTML's fault. Thanks.
|
| It's just the confluence of Quoted-printable transfer
| encoding and the tendency for HTML emails to embed links
| split up and in non-href and other tags that end up not
| getting rendered on my thunderbird fork in text mode which
| means I have to view source and deal with the Quoted-
| printable URLs.
| encryptluks2 wrote:
| First and foremost, I believe most of the issues can be addressed
| using a markup language like Markdown or similar. Accessibility
| clients can be updated to accommodate such formatting as part of
| the standard.
|
| Second, hard wraps should not be mandatory and in fact
| discouraged. If someone wants 72 columns then there email client
| should be the one setting that, not the message itself.
| duxup wrote:
| I love the idea of plain text email. But I don't think it works
| as well with a huge volume of mail most folks get.
|
| As I create emails for customers and such I find some level of
| html / banner / something even beyond the subject is needed to
| help folks filter though all their emails.
|
| In my experience emails with a company banner and large text
| indicating the reason for the email "your order has shipped" are
| spotted quickly by their customers / quickly understood /
| filtered easier.
| JohnFen wrote:
| Using the subject line to indicate the reason for the email
| isn't sufficient?
| 0898 wrote:
| This is why we stick with ConvertKit.
|
| Other email providers make you jump through hoops to send an
| email newsletter that looks like it came from a person.
| vanous wrote:
| I will rather use HTML email via standard federated email network
| and be able to put images inline with text captions describing
| these images, rather than being text only email purist and then
| having to bend over to send images with "inlined" text in silo
| apps like whatsapp, slack, signal or telegram.
| _verandaguy wrote:
| There are some valid reasons to avoid using HTML email (some of
| which are even listed on this page -- like avoiding link
| obfuscation), but my god does this page come off as
| condescending, right from the opening line ("Plain-text email is
| strongly preferred").
|
| The reality is that HTML email's too convenient to go away at
| this point. It fills enough niches both in people's corporate and
| personal lives to ever truly be undone, and having so many of the
| recommended clients being TUI-based (and emacs-based, apparently)
| shows a particular tone-deafness since TUI mail clients will
| almost certainly never be widely-adopted ever again, even by
| people who spend lots of time in a shell. Add on to that, that
| TUI mail clients will almost invariably render monospace fonts,
| which aren't great for reading things other than code.
| vel0city wrote:
| Its also incredibly condescending having them tell me I
| shouldn't format my message as HTML when the message they're
| using to tell me that is an HTML formatted message.
|
| If plain text was more than acceptable to get the point across,
| this page wouldn't use HTML. Instead, they have an inline
| image, they have multiple font weights, anchor tags, inline
| styles, chosen fonts, changes in colors, hyperlinks, bulleted
| lists, etc.
| themadturk wrote:
| But they're two different media. It's like they're saying
| "writing in longhand is best" but you're complaining because
| they're using mass print media to spread the word. Or
| complaining because a book or movie is advertised on TV or in
| a newspaper.
| mrzool wrote:
| This sounds great until you realize that, in the real world,
| people want to have some options to format the text they write
| (italics, bold, hyperlinks and the like), and there's absolutely
| nothing wrong with that.
| Eric_WVGG wrote:
| I blame HTML email on the old UNIX neckbeards who hated on this
| kind of thing. If they had just given us the reasonable stuff,
| the industry wouldn't have had to resort to awful hacks.
| deltarholamda wrote:
| In the real world, people want to have their company logo, nine
| image links to their social media accounts, and a special font
| for their signature.
|
| Then they top post their entire email to a 257 email chain, so
| you have to do a kind of inverted scavenger hunt in order to
| figure out what they're talking about, none of which is
| improved or aided by the company logo, special font, or image
| links to nine different social media accounts.
|
| And I haven't even gotten to grandma's love of emojis to convey
| her appreciation of your ribald joke about cookies.
|
| Email is a tool, and like all tools, it can be grossly misused
| and abused.
| mrzool wrote:
| 1. Emojis are perfectly supported in plain text as long as
| you're using Unicode.
|
| 2. The bloat/ugliness argument could also be applied to
| websites, but no one is out there advocating for plain text
| websites.
| deltarholamda wrote:
| People who use screen readers would probably be very
| supportive of plain text Web sites. Web devs usually do a
| lot of work to make a Web site accessible.
|
| In any event, email and Web sites are completely different
| things. Different communication mediums require different
| communication styles. Advocating for a certain style on one
| does not mean you have to also advocate for the same on
| another. The question would be "does rich-formatted text
| substantially add to the medium of email," and I think the
| clear answer to that is "not really."
|
| An example of a good use of rich-formatted text
| contributing to an email would be coloring responses to
| questions. I see this one a lot, e.g. "my responses are in
| RED." We had the > quote style for this already, which was
| pretty good until an email thread started to get really,
| really deeply nested. In plain-text, at some point,
| somebody would have to edit the quotes down. There was a
| marginal advantage to having styled text to clear this up.
| Was this advantage enough to have to suffer through the
| majority of emails where this was not required and the
| formatted text was rife with extraneous or useless widgets?
| couchand wrote:
| "my responses in red" assumes a lot about the visual
| abilities of the reader. I'm sure there's a better way to
| express this idea.
| kixiQu wrote:
| > no one is out there advocating for plain text websites.
|
| The gemini folks (gemini.circumlunar.space/) basically are,
| but I think it's a similarly niche / reactionary take.
| temp_account_32 wrote:
| Yeah but we wouldn't want to cripple it for everyone because
| there exist some people who abuse it.
| lbriner wrote:
| This is a strawman. How does plain text stop people abusing a
| medium?
| hammyhavoc wrote:
| Their argument is that by not having HTML, people can no
| longer annoy with their use of HTML.
|
| This is a client-side issue, IMO. If someone doesn't like
| HTML, simply don't enable parsing of it and view the
| source.
| jevgeni wrote:
| People can annoy with plain words just as well.
| hesk wrote:
| Including, apparently, the people who created the web site, and
| who use bold text and different font sizes to format the
| headlines, colors to indicate features which are supported and
| not supported, and an image of a "plaintext certified" stamp.
| emasirik wrote:
| It's a bit rude for HN, but from the bottom of the article,
|
| > "But if plaintext is so good, why is this page written in
| HTML?"
|
| > This is a reference document, not an email, you twit.
| vel0city wrote:
| It seems their main point is using HTML is trading
| accessibility and security concerns for prettification. Why
| is a reference document an acceptable trade off of
| accessibility and security concerns for prettier formatting
| but a personal email isn't?
|
| They could have made this site plain text and followed all
| of their own guidelines, but they didn't. Instead, they
| wanted to make the site look prettier to get their message
| across with additional formatting plain text can't handle.
| They're reducing accessibility and increasing security
| issues just for their own superfluous desires.
| adolph wrote:
| Well, this reference document seems to work reasonably as
| plain text. What's that person's excuse for html just
| because it moves via HTTP?
|
| https://www.rfc-editor.org/rfc/rfc5322.txt
| tadfisher wrote:
| Plain text with 80-column line breaks suuuuucks on
| mobile. Give me HTML any day of the week.
| bitwize wrote:
| "How about you use an email client from this century." --the IT
| guy at a place I worked
| AdamH12113 wrote:
| > HTML emails are mainly used for marketing - that is, emails you
| probably don't want to see in the first place. The few advantages
| they offer for end-users, such as links, inline images, and bold
| or italic text, aren't worth the trade-off.
|
| Inline images are a huge, huge advantage, especially for internal
| business communications where an email may be the only real
| documentation of a problem and its solution. (Or at least the
| only documentation that can stand on its own -- the alternative
| is usually a PowerPoint deck with missing information that was
| only given in a one-time presentation.) Being able to add a graph
| or a table or a schematic or a photo is important for anyone who
| works with non-text data. I suspect some programmers may be
| unaware of how unusual it is to work entirely in text.
| queuebert wrote:
| Maybe emails shouldn't be primary documentation. They were
| never designed for that, and shoehorning them into that role
| has ruined the entire experience.
|
| For example, my workplace no longer allows forwarding or IMAP
| access because of this, so I'm forced to use the sh*tty Outlook
| web client, which wastes untold numbers of minutes each day
| waiting on the damn thing to load something. Just now it
| wouldn't let me open a PDF in a native client, because I guess
| Microsoft is so obsessed with locking us into their ecosystem.
| Instead I had to save it to disk first then go to the file
| manager to load it. (Yo, MSFT, this is why people hate you.)
| AdamH12113 wrote:
| I strongly agree, but good luck pushing that idea in your
| nearest large corporation. The lack of concern for
| communication and record-keeping I've seen in my career is
| simply appalling. Simple things like minimal proofreading are
| treated like pulling teeth, and heaven forbid someone rename
| a file so you can actually tell what's in it. At least an
| email is a proper written document, unlike the half-assed
| PowerPoint slides I usually see.
| Nux wrote:
| Try Davmail, bit slow, but better than nothing
| [deleted]
| OJFord wrote:
| In pouring over the relevant RFCs fairly recently in order to
| implement my own client, I learnt (though didn't implement -
| raised a not implement exception, and I've yet to receive
| exceptional mail) that you don't actually need HTML for inline
| images.
|
| Tl;dr a multipart message can include an image with an inline
| 'content disposition'. It's intended that clients show it
| inline, but I suspect many don't. Like I said I haven't
| received any yet anyway, so it's probably not that
| consequential.
|
| Another quirk I'm aware of, by implementing my client quite
| unforgivingly, is that many emails are structured with the
| attachments only 'tied' to one alternative, often the
| text/plain media type, so if you interpret the parsed tree
| structure of alternatives/attachments literally, the HTML-
| formatted message might refer to an attachment (I mean a PDF
| say, not an embedded image) that's actually only available on
| the plaintext version. Having never encountered this before,
| I'm pretty sure other clients (like Gmail, Fastmail) present
| all found attachments alongside whichever alternative is
| viewed, not taking the actual email too literally (as I
| presently do).
| usrbinbash wrote:
| Images can just be added as attachments however, they don't
| have to be inline. Many GUI mailbrowsers can display them as
| previews. If for some reason they are absolutely required to be
| inline of text, its easier on the recipient of the message, if
| the document is composed as a separate file (pdf or whatever),
| and sent as attachment.
| soheil wrote:
| What really bothers me is when someone copy and pastes
| something they've written in MS Word into their email and
| turning the email into HTML without even noticing. What's even
| worse is when people bump up the font size of the entire email
| body because they think since their email client has a small
| default font size it must be the same for everyone else, I've
| seen tech CTO's do this to, sometimes you wonder what the
| technical chops for a position like that really is.
| upofadown wrote:
| One nasty thing that Word does in this situation is to
| effectively convert any included jpegs into pngs. That cute
| little pic you included as a header is now 800k when it hits
| the email list.
| AdamH12113 wrote:
| Yeah, rich-text copy and paste is pretty awful. The default
| in almost all cases should be "paste without formatting", but
| instead you have to go out of your way to exclude formatting.
| usrbinbash wrote:
| I was so happy when I figured that chrome based browsers
| now have a "Paste as plain text" functionality. I receive
| technical problem descriptions in (of course) HTML email
| formats, and copy pasting them into the archive systems web
| interface (which ofc is also rich text based) always was a
| PITA.
| wizofaus wrote:
| This has been bugging me more and more recently - the
| assumption that if I've copied a few words from one app
| then pasted it into another it means I want to preserve all
| the formatting is wrong 99% of the time, yet there are now
| popular web-based apps (Confluence being one example from
| memory) that don't even support "paste as plain text".
| Actually what I typically want is "smart paste" which
| implies preserving _changes_ in the formatting, and
| supporting e.g. hyperlinks etc., but ignoring whatever
| formatting attributes happened to be active at the
| beginning of the selection. But I 'd rather lose support
| for rich text paste entirely over the situation we have
| now.
| soheil wrote:
| Agreed. I typically copy whatever text and paste it in
| the address bar and copy it again to lose the formatting.
| It also loses any line breaks but still worth it.
| JohnFen wrote:
| I keep a simple text editor open to accomplish that with.
| You keep line breaks that way.
| wizofaus wrote:
| That's my usual trick too but it's a terrible hack.
| Windows in general (I don't think MacOS is better) is
| crying out for more sophisticated built-in clipboard
| support, including supporting multiple active items (3's
| probably sufficient), and better conversion/formatting
| options (even to the point of automatic OCR etc.).
| BitwiseFool wrote:
| Those things you mentioned are a-ok, but including a photo in
| the email signature really bugs me. There are times when I want
| to look for emails with an attachment, but often the company
| logo in the signature causes false hits.
| djbusby wrote:
| You can send a plain text with attachments? That's how I used
| to do it (1996-2022)
| anamexis wrote:
| I think the keyword there is "inline."
| adrian_b wrote:
| Many e-mail clients display the photos attached to plain
| text e-mail messages as "inline", you do not need a HTML
| message for that.
| solarkraft wrote:
| So how do I put text between them?
| marssaxman wrote:
| Send your formatted document with embedded images as an
| attachment.
| anamexis wrote:
| You could even send it as an HTML document, and if your
| email client supports it, it could display the document
| right in the client!
| adrian_b wrote:
| While this is something that I do not remember using,
| because I typically attach all the pictures at the end of
| the message, all the e-mail clients that I have used have
| 2 menu options while composing a plain text message:
| "Insert file" and "Attach file".
|
| I believe that "Insert file" should insert a picture in
| the middle of the plain text, unlike "Attach file".
| OJFord wrote:
| For that I think you have to use text/html so that you
| can reference the inline image's Content-ID. The rest of
| the 'HTML' could be plaintext of course, just needed for
| the <img>. You could also have related text/plain and
| text/html only for wherever you need the image - but
| support of that is probably even patchier than inline
| attachments.
| dtjohnnymonkey wrote:
| I wonder if the point would have hit harder if the website was in
| plain text?
| lkrubner wrote:
| HTML is what killed email. The younger generation hates email in
| part because they associate email with spam, and spam email only
| became a large business because of HTML email. Plain text email
| could not easily be used for advertising, nor did plain text
| email support clever, manipulative tricks, like embedding hidden
| images so as to track people without them being aware of being
| tracked. Also, HTML email was implemented without enough thought
| as to the security and privacy problems it allowed, and it took
| 20 years to lock down HTML email to limit the damage to security
| and privacy. Plain text email was a great communication
| technology, and fairly immune to spam. I've often thought we
| should re-launch plain text email as some new, separate protocol.
| A wider demographic would be willing to communicate with plain
| text email, just as a wider demographic is comfortable with text
| messages on their phones.
| nuancebydefault wrote:
| Spam heavily uses styling and formatting features of HTML.
| Similarly, paper advertising uses a lot of color and glossy
| paper. Saying that HTML killed email is like saying glossy and
| colorful print killed books.
| brewdad wrote:
| Tracking bugs in images is what killed HTML in email. For my
| security and privacy I have to block all external content by
| default. This means I get a ton of marketing emails that are
| either blank or missing the important bits unless I choose to
| load the external content.
|
| The end result is that they almost always get trashed unread.
| I might actually be missing out on a useful new product or a
| great deal but I'm not going to bother with the extra clicks
| and unknown risks because marketing wanted to make it pretty
| over making it accessible.
| res0nat0r wrote:
| I'd love to use mutt for my mail email client every day, but it's
| essentially impossible to use especially for work context without
| me risking missing important emails or having to spend way too
| much time fiddling with viewing html emails from other companies
| / coworkers in a reasonable fashion via the mutt TUI so
| unfortunately this isn't going to happen for me.
| alexwennerberg wrote:
| As a compromise, I have a key bound to open a web browser to
| read any html-only emails. I find it to be the best of both
| worlds.
| krossitalk wrote:
| Imagine trying to read that very website as a plain text email.
| The headers, bolding, and rulers make a huge difference.
|
| Plain text email reminds me of the original ethos behind
| Markdown. "You're already doing it". Except, not everyone has the
| same rules. We can all read it but there becomes necessary a
| translation layer.
| UncleSlacky wrote:
| On a similar note, the ASCII Ribbon campaign:
|
| http://www.asciiribbon.org
| UI_at_80x24 wrote:
| Know your audience.
|
| I default to plain-text 99% of the time. In my corporate world I
| am FORCED to embed excel tables, colour-coded replies (Bob's
| replies are in RED, Alice's replies are in GREEN) [fuck the
| colour blind].
|
| And I hate it. So it's only those emails that get it. I have been
| forced to conform. Outlook is still configured for plain-text
| email, and bitches about it whenever possible.
|
| Everywhere else, plain-text only. Resistance is futile.
| funnybookbinder wrote:
| I run into difficulties with text-wrapping in plain-text emails.
| If there are nested quotations, the wrapping can get jumbled,
| especially if reading on a small screen like a smartphone. Don't
| have that issue with html emails. Am I doing something wrong?
| progval wrote:
| It means the sender did not use format=flowed
| BeetleB wrote:
| format=flowed doesn't work on all readers. I have
| format=flowed turned on and it still doesn't display as
| properly wrapped on various email readers.
| scblock wrote:
| No, the specifics of making sure plain text email wraps
| correctly are just complex enough it might as well be html
| email. It's 2022, and in this day and age the concept of
| sticking to 80 columns of plain text is outdated and mostly
| reactionary.
| rhn_mk1 wrote:
| You're not doing anything wrong, it's the people who insist on
| hard-wrapping emails they send are who's wrong.
| petercooper wrote:
| I was keen to try out 100% pure plain text emails and ran into
| this problem too. The reading experience on mobile wasn't good,
| and that's increasingly where people are. Very spartan, minimal
| HTML resolves all the problems, but then you're back to HTML.
| JohnFen wrote:
| If all that was used was basic HTML formatting tags, I'd be
| fine with it. But that's not what it is.
___________________________________________________________________
(page generated 2022-09-12 23:02 UTC)