Can I Email?
caniemail.com
caniemail.com
This is actually a great tool to find vulnerabilities in various webmail clients such as ProtonMail and Hey, just compare the HTML or CSS features they do not yet filter compared to Gmail, then do a search for "[feature] + exploit" to see how a feature could be abused, and then submit a bounty report.
For example, there are alot of good reasons that you may not want your webmail rendering SVG images (mXSS, appcache poisoning) or allowing CSS variables or imports.
And I'm pretty sure the list supported by Gmail could also be narrowed down further. There are some fantastic bounties lurking in here, just waiting to be discovered.
And sites with strong CSPs are often especially vulnerable to scriptless attacks, perhaps because they feel more protected. For example, in 2019, there was a bug bounty disclosure to Fastmail about a way to intercept and proxy all email attachment downloads, completely client-side, and yet without involving any JavaScript, simply using HTML5 AppCache. This also affected a whole lot of other providers, but the Fastmail team patched this within 24 hours, a pretty amazing response, and the quickest by far.
Here's a fantastic paper from Mario Heiderich (of Cure53) from 2012 on various kinds of scriptless attacks: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46...
is PDF. Yeah, PDF has drawing commands. Most vector formats are based on command sequences, that map 1-1 with what you'd find in a drawing library like Cairo. EPS and PDF both work that way, which makes it even more of a typical vector format than SVG (which only does the command sequence thing with paths, AFAIK). Of course, it's not that well supported (the in-browser reader does who-knows-what to get it to render, I think it's converted to DOM elements), but it is the other major browser-supported vector format.
Those nth-child* selectors Gmail strips out are a real security nightmare.
No thanks. I still recoil at the sight of a read-receipt and the only reason most companies include any of this dreck in an email in 2021 is to either track me or market to me.
make email text again.
To expand a bit: With css, you can specify a background image to any document element. Something like this, where the url serves to identify you:
div.foo {
background-image: url('https://example.com/bar.png?t=deadbeef')
}
That ship sailed the instant it got named "email" instead of something like "etelegram".
With mail, I can send anything that my printer can print, which is everything my word processor can handle (fonts, text decoration, foreground and background colors, inline images, graphs, tables, and more) and attach anything that fits in the envelope (a CD-ROM of arbitrary data in any format).
It was inevitable that email would end up being able to handle the electronic equivalent of all those things.
The problem with email is not that it now handles more than just plain text. The problem is that there was no early agreement on how to handle those things, so different implementors came up with different ways to do it, which eventually converged on using HTML. Not because HTML was necessarily the best way to do it, but because it was something they all already implemented for other things or was already available on the systems their mail clients ran on.
But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
That should work to each party’s satisfaction.
Just sending something registered won't help your jurisprudence :p
Likewise, if it's refused, it's on the recipient to be responsible for whatever they didn't accept
What would you think only makes sense for the web and not for mail?
Good email clients already provide a very simple solution: a user option to disable loading remote content, with a per-message option to load it.
Your suggestion would mean that my mail client has to download a ridiculously larger volume of data than it does now.
Sure, I'd love to only send txt mails but that sadly does not align with the expectations/desires of the companies I've worked with.
You can load plain HTML as a .eml template into it and send it off... but not on Windows, you're stuck with some weird undocumented binary format there.
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?
And from that perspective, it's better to break the mail as it's coming in (so the sender gets blamed) rather than at the moment the user clicks reply.
Send me plain text email.
Add attachments that I can scan for issues before I open them.
If you send me links, I will be very wary of visiting them outside a sandboxed tab. I will not 'click through' from the email client.
I got a link to re-up a certain type of account from my bank. It was very odd, I was quite confused.
I’m not interested in learning MJML. I’m interested in learning what subset of HTML and CSS email clients render and rasterize to.
That’s it.
I’m sick of stupid developers shilling their software product that I’m suppose to build other products with.
They do it with these cutesy photoshop/illustrator logos and dribbble crafted color schemes and drop in things like made with love in (city) in their README.mds on GitHub.
I want tools, not someone’s amateur marketing campaign.
Doesn't sound like you want a framework. Sounds like you want a book.
Tools like MJML take a compiler approach to email. Why waste time trying to figure out how to implement a for loop in machine code and keep it updated every time a new processor comes out when you can just let the compiler do it?
The idea we need compilers for everything is idiot engineering.
And even that isn't trivial. For example, say you include an basic black on white icon, what happens if the user is using dark mode? If the image is transparent, it becomes entirely invisible. If it's non-transparent then it's ugly (white box). If you want to make it change depending on dark or light mode, now you have to use responsive CSS which works entirely differently in different mail clients. What happens if the image is bigger than their viewport? Hint: it is different in different clients.
And speaking of mail clients: one of the most popular mail clients is Outlook, which on Windows uses the Microsoft Word(!) HTML renderer and on Mac it uses WebKit. Gmail on web has its own HTML parser that outputs different HTML to what you wrote (and mangles your CSS class names). Apple Mail is probably the easiest to deal with.
It's not worth learning this stuff if you don't have to. It will not benefit your life in any way. The common subset you want is text/plain.
You can use Table and all its related fields, span, h_, and p. Anything else is risky.
For CSS you can set the font color and size. Setting a font itself is risky. Avoid using anything else including margins and padding as these largely don't work properly. multi layered tables are your margin and padding system. You also can only use inline styles. No classes, style tags or linked styles.
Thats about it for email. Have fun.
Asking because all I know of it is from their site. I have not used it myself. Does it have its own glitches that come along during the attempt to patch over other glitches?
It’s also easy to teach to designers.
I customized them, extracted them into modules and created a design system which I then translated to an email CMS.
Coverage is pretty good although Outlook still glitches in some circumstances.
https://tedgoas.github.io/Cerberus/
FWIW caniemail is unreliable and does not have full coverage.
Also with this level of complexity I’d rather start with a few tested patterns than navigate the insane labyrinth of email client inconsistencies.
I made what they wanted with MJML. Looked good in a browser, gmail and phone.
Outlook had a few issues, can't remember which right now.
But replying from Outlook simply broke the styling completely. Gaps between each section, complete mess. Not the impression you want to give the customers when their order goes wrong. B2B means Outlook is what out customers use.
I've found that replying via Outlook is the ultimate integrity test of an eamil.
Now I'm making them by hand and it is a madening cargo cult bonanza. Takes a lot of time.
I guess MJML is fine for marketing.
This is an Outlook problem, not an MJML or even an HTML problem.
If you inspect the HTML for the email sent vs what Outlook sends on a reply you’ll see it has changed the code.
Here’s an excellent highlight of this bug https://www.hteumeuleu.com/2016/super-mail-forward-an-email-...
Are you complaining that his boss is forcing him to implement something that his end users can use?
If so, why isn't his boss right?
Personally, I'd say that yeah, he's supposed to work for his end user, why would he do anything else?
For example, if the org uses desktop Outlook but < 1% of your audience does, is it worth optimising the email for that audience based on internal feedback?
If someone notices that something weird happens when an email is replied to or forwarded, is that something worth acting on based on the real world frequency of that action?
Though you are technically correct, I just don't think this is a constructive attitude. Half the job of making emails is working around (Outlook) bugs. This is just the annoying world email coding.
If MJML is content ignoring Outlook bugs, MJML just isn't a satisfying tool for email makers.
Sure, it'll get the job done for some marketing, but now the developer isn't learning skills that will make robust emails beyond that.
Making robust emails becomes a completely separate skillset and the developer who chose to invest time in MJML will have to start all over learninging the necessary skills if he needs to make email you can actually reply to.
I’ve worked in email for a decade, you do what you can with the tools you've been given. An email will never look perfect everywhere and while I agree with the general sentiment you’re talking about regarding folks learning proper email code rather than relying on tools, I also think the quality of emails sent is substantially higher now thanks to those tools.
This is a problem area where a good abstraction framework is highly useful in my opinion.
That said I don’t specialise in email, it’s something I do “when I need to”. So if I was spending more time doing this sort thing, I might be more inclined to move down an abstraction level back to HTML/CSS and improve my knowledge of various client support.
To just get the job done though, MJML is highly recommended.
I see also a lot of mentions on this thread about replying to emails breaking the layout. Part of me thinks we’re fighting a losing battle here anyway so there is a limit to how much time it’s worth spending to make sure even replies are formatted nicely across all clients. But the other thing to consider is whether the email template is just trying to do too much.
I try and keep my email templates very sparse, clean and simple and I generally haven’t had too many issues with reply/forward formatting (that I’m aware of).
I would love something like very simplistic markup, doesn't even have to be HTML. Just something to inline some images and differentiate text.
Everything else is just horrible.
I get so many emails with basically websites in them, but when you click on a product, the deep link is broken and you just end up on the storefront.
I'd much prefer a small text that talks about the product and explains a few things and then a working link to that product.
I suppose "Your mail program is broken and can't read our message. Please go to this URL" is worse, though.
Settings → Preferences → Show advanced preferences → Reading → View HTML, select Always display messages in plain text.
Settings → Preferences → Show advanced preferences → Compose & Reply → Compose format, select Plain text, plus untick When replying, use the same format as the original message.
I don’t think this is such a rare feature, though it’s generally not made obvious at least.
What I mean is I wish companies would send their transactional emails and newsletters in plaintext. Images and the like could be sent as attachments, as opposed to creepy weblinks that track your opens and IP and everything.
I would pay each company $0.10 if they offered me the option of receiving all their emails in plaintext like this.
And you'd also need to be able to somehow force them to <<only>> monetize you through direct payment, because what most companies do is, take your money <<and>> also sell your data, on top of that.
But this is hilariously false. Nowhere near “most” companies are selling your data.
In fact, an overwhelmingly vast majority of all businesses don’t sell your data. This is true inside Silicon Valley and even more true outside of the Valley.
Even in Silicon Valley, most companies understand that selling products and services to customers is more profitable than trashing a customer relationship by selling a customer’s personal info to third parties.
I think people use 'selling my data' as an (inaccurate, sure) shorthand for 'collecting so much data about me and I don't really trust them not to sell it at some point'.
That's because they haven't figured out how to. Or at least how to do it to make it worthwhile.
Secondly, we're all doomed. I recently read an article about Amazon's ad division being as big as AWS and growing as fast, if not faster:
https://www.ben-evans.com/benedictevans/2021/3/14/do-amazon-...
If even AWS isn't bigger and isn't growing faster than ads, what hope is there, really, for someone trying to just sell stuff?
(Preferences -> Mail -> Composition -> Default method to compose messages: "Plain Text")
Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196 comments)
I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
Have you considered emacs with notmuch and the Gnus renderer? It displays most HTML emails well, and when it doesn’t then a browser is just a quick ‘. b’ away. And of course there’s no need to integrate an external editor, because it’s integrated within the editor!
As a plus, it is simply amazing how quickly one can search local email.
Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
RFC 1896 specifies text/enriched: https://datatracker.ietf.org/doc/html/rfc1896
And of course nowadays there is Markdown, which basically codifies a lot of earlier plain-text formatting conventions.
> Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
I don’t know about that, really. We got by fine with plain text messages for decades, and the formatting conventions were good enough to convey meaning and nuance.
I don’t think that HTML emails are really an improvement: full-fledged HTML engines bring in too many opportunities for exploits and privacy loss. They definitely add capability, but at too high a cost IMHO.
In general, I think that our industry would benefit from asking ‘can we?’ less and instead asking ‘ought we?’ more.
However, my thread is more "can we do it differently?" instead of "maybe we shouldn't do it at all"
I agree, HTML isn't right for email.
Some different approach, possibly a markdown variant, with decent style support (basic css like background colours, fonts, like markdown themes in a code editor), why not explore that.
There's no reason emails need to be plain. RTF is a horrible format, markdown is much more prevalent and easy to make a simple UI formatter that obeys the standard for non technical users.
Once email was in wide use by the general public, easy formatting was inevitable. HTML was everywhere, and so was the path of least resistance.
I thought it awful at the time, but "at the time" was literally more than two decades ago. HTML email is fine. MOST mail I get, professionally, has some formatting in it now. MOST mail I send probably does, too, to increase what a mentor of mine used to call "scan value."
Could I put all that in a Word doc and email THAT instead? Sure. But that would be a huge pain in the ass.
There are plenty of use cases for <li>/<h1>/<em> in emails, and with some nice default user styles they can give everyone a pleasant experience.
Sadly, CSS is often applied and the HTML people write is often broken.
But don't put every keypress from my searches into my browser history.
Am I wrong with this assumption?
I also think, though, that any open source client likely does a good job regardless of feature density, since its likely going to use well vetted code in core components.
Saying that, for example, Microsoft's or Apple's code isnt well vetted is unfair, but the amount of eyes that have seen the Microsoft html renderer vs the, say, WebKit one, is likely smaller and less diverse.
This is specifically focused at HTML specs/features, and a fork of https://github.com/Fyrd/caniuse
Targeting HTML rendering engines which are email clients.
Fortunately (at least for some of the newer features to be included) Links to MDN are available, and caniuse both link to we spec). CSS min for example is working draft. https://www.w3.org/TR/css-values-4/#math-function
With 90% desktop/mobile browser general usage support, 50% email usage support.
The feature definitions seem to be maintained manually, at https://github.com/hteumeuleu/caniemail/tree/master/_feature...; assuming it follows the caniuse.com community model, information about supported browsers is similarly crowdsourced.
(And what about Linux?)
From my experience, all versions (Windows, macOS, Linux) have the same features.
These days, I disable Javascript on any site which has the audacity to put a popup in the middle of the page as I am reading it. Any site with is not readable without Javascript is one I leave and don’t go back to.
The kinds of sleazy outfits which do not honor unsubscribes are the kinds of places email providers are really good about black listing.
I think you need some example search b/c I was not sure how to use the tool at first.
We use MJML to ensure compatibility in all mail clients, which works fine. Although MJML is much less flexible than pure HTML.
That being said, I can see the usefulness of this tool for developers, I just wish people would rely more on plain text.
Email serves every type of business, yes more could be just text - but some will never be served by that format.
When they see a plain text email from a site they would be more likely to think they are being scammed than to be impressed at its simplicity and ability to display in the terminal.
When every website is hacking around broken table layouts to get them to render in outlook (essentially Word), something is wrong and should be fixed.
> Because several of these constraints have been remedied over the years, many of the concerns that users had about subscribing have disappeared.
Read: Because we stopped asking permission and instead started spamming everybody who gave us their email address, people stopped thinking that not subscribing had any effect.
> The increase in sheer email volume over the years has created a scenario where people can’t possibly give all messages their full attention, so they care less about what they receive because they know they can easily ignore the noise or choose what they invest their time in.
Read: Our entire industry spams people so much that people know it's not worth reading.
> It’s no longer used strictly to describe unsolicited email messages. Participants in our study used the word “spam” to describe solicited marketing emails that they considered random, impersonal, irrelevant, with too much promotional hype, or coming in high volume.
Read: We required an email address for things that don't need one, then treated that as permission. How dare people consider our spam to be spam?
> Now that organizations are required to include an Unsubscribe link in their newsletters, this task has become easier.
If a company assumes that an email address given for identification can be used for marketing, or that it can be shared with third-parties/affiliates for marketing, then they are already pretty shady. I honestly have no way of knowing whether it's an actual Unsubscribe link, or whether it's a signal that the email address is actively read by a human and so should receive more spam.
> If users keep getting unwanted newsletters, the messages will start to backfire and become regular reminders that they’re annoyed with your company. Better to let them go.
This part I do agree with. Better still would be to not assume permission to send marketing to somebody just because there was a pre-checked both on a form.
This community is as much an echo chamber as anywhere else. Just because an opinion is common here doesn't mean it's correct or reflects the wider population.
I really don't think that that's true.
Taste is generated. Cool trendy startups make "nicely designed" emails, users come to expect that. If scam emails looked "nicely designed" and Google sent emails in plaintext, the "nicely designed" emails would be considered untrustworthy. As a counterpoint, an "average user" wants software to work, and forcing every email client to parse HTML (which is far outside the scope of what an email client should do, especially with html as complex as it is today) often breaks things in unexpected ways.
In my opinion, html and plaintext are both inappropriate for email. HTML is far too complex, and plaintext is a bit too simple. I think a markdown-like syntax would be the best balance, but I'm pretty sure that ship has sailed.
As far as I know, only old (possibly pre-Tiger) Mail.app in Mac OS X used to produce it.
I've corresponded with others, also German, and they had the same preferences, even if not as explicitly stated as the examples in my other comment there.
This is not an endorsement of the practice, just an observation.
Among this sea of garbage, there are rare islands of useful updates - like genuine newsletters I subscribed to, or email from my doctor about test results, or reminder from my bank that they are going to deduct that car payment, whether I like it or not, so there better be money there, etc. And of course Amazon shipping notifications! If all those need any HTML, then only the most rudimentary one.
Of course, if you asked a user whether they'd want to get ugly marketing spam or beautiful one, I guess they'd choose the beautiful one. But that's not the right thing to ask.
Indeed. The number of HTML elements in an email scales pretty linearly with the probability of it being spam.
Plain text is almost 100% certain not spam.
Nearly 100% of spam is plaintext, a small fraction uses badly designed HTML that barely displays in the client.
If it doesn't have this link, it's spam. If it's trying to get me to buy something I didn't explicitly wishlist on a store, it's spam. If it's unsolicited marketing, it's spam.
And even if I were to include all marketing email, including those I am interested in, then plaintext mail would still constitute the majority of spam mails I receive.
I very rarely get marketing mails from any reputable company that are completely unsolicited. In most cases it's a followup from trying out an offering or updates to products I'm using or are adjacent to those. If I'm not interested, I either ignore them or unsubscribe if it's repeatedly not interesting.
This is a much more effective "spam" strategy compared to "all HTML is spam".
Whenever I have to interact with a company, I check the spam folder for their replies.
The majority of mails in my spam folder is html mail.
I can recommend using the unsubscribe link if you forgot to uncheck the newsletter checkbox during registration. Alternatively send them a mail to A) remind them of the SPAM-CAN act or your local equivalent legislation and B) that they should delete your mail from the newsletter. That works almost always, if not you can always threaten legal action (where I live, that's an easy 600€ of profit in a courtroom).
Not all is as sinister as it looks.
The simply solution is to just can any senders that don't respond to unsubscribe requests. But those will be just as bad in plaintext as in HTML, so I don't see why Plaintext means it's not spam, they can do the same thing Plaintext.
In my observations badly formatted spam exists, but have big intersection with the spam which is relatively easy to filter out. Nicely formatted HTML spam on other hand is hard to filter because the only difference with legitimate marketing email is lack of any consent from the sender. Sure I can hit an unsubscribe link and my be never will get spam from the same domain again, but spammer will know that this email is active and will include the address in spam send on behalf of other customers.
Spam usually has bad formating, mixed charset, old/broken layoyt etc.
Most of time, spam are odd designs. Example they only have HTML and didn't have the corresponding plain text part. They have large pictures and too little text, they have many "invisible" part so that hide behind element to trick you to click the wrong thing.
Even in plain-text, spam tend to include random links, very long text, weird chracter etc
A nicely design, or a plain-text emails(only plain text) with nice format all are good signal of non-spam.
In other word, consistency is signal of non-spam emails. But sometime marketing emails-which you never explicitly subscribe to, you just register for an account and got marketing emails, can also be consider spam, but from google/hotmail point of view they don't consider these are spam and that's reason they have Promotion tab to put thing in there
---
"Nicely designed" emails are things like flight confirmations, invoices, shipping notices, and that kind of transactional email. The common thread is that some entity with Real Money To Spend on a graphic designer is sending a (usually form) email to lots of people. Most spam outfits do not have those kinds of resources, especially since they need to change up their emails constantly to avoid spam filters.
The closest I would say that the "pretty" stuff gets to spam is newsletters and particularly political fundraising emails; I'm on a lot of political party lists after spending copious college free time working on campaigns.
And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
And yes, the subset of spam that's most recognized - ED pills, reproductive organ enlargement, members of royalty looking for help managing their finances - they tend to be very simply designed. But their distinguishing feature isn't simplicity of design. It's the carelessness. Typos, bad grammar, highly visible formatting mistakes, etc. When, on occasion, one of that "old school" spam messages tries to pose as a legit transactional e-mail, you can see through the deception by noticing the carelessness in replicating the design of the company being impersonated.
This is just plain untrue, and seems to color your impression of email as well. See e.g. Delta vs Southwest (more polished look is more ergonomic site/app), or New Relic vs Datadog public-facing sites (indistinguishable in "quality" of the design, for competing products where IMO Datadog is better).
What are some examples that put the inverse correlation in your mind?
Do they? Do they really like it? Did anyone actually asked? And no, A/B testing your design's capability to trick the user into paying you money isn't measuring whether they like it or not.
I have an alternative proposal: average user just accepts what they're given, because they have no other choice. Nobody listens to their opinion (again, tracking and telemetry is not the same as listening to people). Abusive designs and patterns are adopted industry-wide very quickly, so there's rarely an opportunity for the user to vote with their wallet - after all, they can't choose something that's not available in the first place. On top of that, the average user lacks the mental models and language to conceptualize what is wrong and how much better technology could be if it was slightly less abusive. All they can do is accept that computers are annoying, and casually complain about this to friends and family.
Oh yeah, they do like it and want it. That is why they use it. And yes, I talked with a guy who was literally like "I like the emails colorful and such, but we found through testing developers respond better to plain, so I send plain to them".
Sometimes we are the odd ones and that is ok.
There's a reason the most popular media is video and images and the main social media platforms are practically platforms for sharing video and images.
The average person all over all the world is almost functionally illiterate (literacy level of a middle schooler or maybe high schooler, at best). They really, really don't want text. They'll only read as much as they have to, and they will definitely choose images over text if they can.
At the end of the day if you see another blob of text, you either skim through it looking for what matters or you just delete/archive it.
They could even hate it, but it just stands out for better and worst.
This is no different from snail mail, where important communication is usually on standard white paper while ads are high quality prints on nice goossy paper.
And obviously, "average users" notice the pattern. Just like my father who almost trashed an important tax-related mail just because it looked too nice, he thought it was an ad.
So the "average user" prefer to see nice ads, I can get that. But what the average user really prefers no ads at all.
Or worse yet, when the plaintext alternative version is broken/incomplete.
I regularly receive mail where the plaintext alternative version has templating variable names instead of actual values, where the html version has the values.
Also, systems that send mail where the plaintext alternative version is only something along the lines of “Your email client does not support HTML. Please read this newsletter at” and then a link. But of course, my client can read html too, I just have it set to view the plaintext version by default.
One of these days I will probably just set it to always prefer the html version instead. I use mutt, with elinks taking care of html to plain text conversion. I’ve been running my mail server for years.
But anyways it might soon be time for me to switch to hosted mail. I have a provider in mind.
Remote images are a crime, break the ability to search ofline or keep a record of ones conversation but they have one key advantage for brands which is to spy on you.
The only non-web client I've used much in recent years is aerc, which is basically covered under "mutt" in this case.
https://web.archive.org/web/20160417105503/http://www.gnksa....
(If your client interprets them, then you're not actually asking for plain text anymore.)
Making it unobtrusive enough to still look good when uninterpreted is a good goal. But that's very different from having nothing at all.
And there was a long history (about 100 years) of monospaced, mono-sized, typographic conventions based on typewriters and cheap reproduction (carbon paper, spirit duplicators, xerography), before the desktop-publishing era brought us out of that in the 1980s. The problem with formatting is that, like Johnny Rocco in Key Largo, someone always wants more, and not for your benefit but theirs.[1]
#ThisIsWhyWeCannotHaveNiceThings
https://news.ycombinator.com/item?id=27114500
In the Web world, counter to an argument elsewhere in this thread (https://news.ycombinator.com/item?id=27113404), my experience is that Web design isn't the solution, Web design is the problem. Straight ASCII text (via w3m or other text-mode browsers), or Reader Mode (where supported) is vastly preferable to many, many nines worth of sites' prescribed designs.
One thought I've had is that user agents could provide, at user discretion, additional typographic control to sites. But for the basics you're limited to 7-bit (not 8) ASCII. Everything else is earned, and you'd best degrade very gracefully.
I've seen websites written where every individual paragraph has an explicitly-specified location. I've seen blogs written entirely in header-level tags. I've seen writers who add nonbreaking whitespace to the start of every paragraph. I've seen blink, marquee, and carousel abuse. I've seen foreground and background colours you wouldn't believe. Attack ships on fire off the shoulder of Orion....
________________________________
Notes:
Inputting by hand (or maybe with a script - who cares anyway?) random Unicode characters to show that rich text is actually possible is the opposite of "smart" in a discussion between reasonable adults.
Yep, that was me that time as well.
> Inputting by hand (or maybe with a script
I did it by hand. There are websites to do this, but I’m not interested in doing this for any regular purpose, so I don’t think I have them saved. Besides, it’s more interesting to do it manually; you learn things about how Unicode works if you involve yourself in the low-level details once in a while.
> the opposite of "smart" in a discussion between reasonable adults.
Or maybe it’s humorous? You know, fun?
Fun?!? On my HackerNews?!?
Burn the heretic!
Most people are unaware that Unicode has that kind of character and even fewer people know what it does to screen readers.
The difference between showing off knowledge and trying to be show people a cool thing you know about is intent and it's REALLY hard to get that across on the internet.
Agreed, that's why I like emojis, for example. They're whimsical, and they increase a bit the bandwidth of written communication.
Alas, HN doesn't support them because of reasons ¯\_(ツ)_/¯
You could specify "Content-type: text/markdown" if you want Markdown (although I don't know which email clients will understand that), although I think that plain text is OK.
I also dislike email newsletters or email discussion lists; either way, I would prefer NNTP.
- Plain Text Mode
and
- uBlock Origin Extension is available (that can block also embedded JS)
People underestimate the attack vector of emails. I'm glad those scammers haven't figured out (at least until now) how XSS could work in Gecko with XUL. Heap spraying could easily be a thing, given that MS Outlook also still uses their outdated rendering engine.
Say you’re a webshop and a customer has signed up for you “newsletter” then you kinda need HTML emails to show your advertised product directly in an email client.
Unfortunately, desktop Outlook is miserable with HTML support [1]. In particular, code blocks and quotes become an unreadable mess. The only way that I've found to include readable code blocks is to copy from VS Code, which somehow has the magic HTML combination that Outlook understands.
For the sake of presenting marketing (Logos). Disgusting. Wear a mask, write text.
Totally different. Try for one week to substitute every sent/received email with web articles instead.
It's like a cake and an elephant not being essentially the same, just because they're both made of atoms.
Edit: i realize this comes off as snarky, sorry. It's meant as a joke. It's reasonable to say that its likely not popular enough.