惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tenable Blog
博客园_首页
Vercel News
Vercel News
WordPress大学
WordPress大学
美团技术团队
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
Y
Y Combinator Blog
博客园 - 【当耐特】
量子位
酷 壳 – CoolShell
酷 壳 – CoolShell
The Cloudflare Blog
T
The Blog of Author Tim Ferriss
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News
云风的 BLOG
云风的 BLOG
腾讯CDC
M
MIT News - Artificial intelligence
爱范儿
爱范儿
Recent Announcements
Recent Announcements
雷峰网
雷峰网
Last Week in AI
Last Week in AI
宝玉的分享
宝玉的分享
The Register - Security
The Register - Security
Jina AI
Jina AI
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Hugging Face - Blog
Hugging Face - Blog
P
Privacy & Cybersecurity Law Blog
Recorded Future
Recorded Future
Help Net Security
Help Net Security
N
News and Events Feed by Topic
博客园 - Franky
P
Proofpoint News Feed
L
LINUX DO - 热门话题
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
月光博客
月光博客
D
Docker
Google DeepMind News
Google DeepMind News
有赞技术团队
有赞技术团队
IT之家
IT之家
Security Latest
Security Latest
L
LangChain Blog
V
V2EX
阮一峰的网络日志
阮一峰的网络日志
J
Java Code Geeks

Mathias Bynens

A horrifying globalThis polyfill in universal JavaScript JavaScript engine fundamentals: optimizing prototypes JavaScript engine fundamentals: Shapes and Inline Caches Asynchronous stack traces: why await beats Promise#then() ECMAScript regular expressions are getting better! Unicode property escapes in JavaScript regular expressions ES2015 const is not about immutability Valid JavaScript variable names in ES2015 Unicode-aware regular expressions in ES2015 PBKDF2+HMAC hash collisions explained JavaScript has a Unicode problem Processing Content Security Policy violation reports Hiding JSON-formatted data in the DOM with CSP enabled Loading JSON-formatted data with Ajax and xhr.responseType='json' Reserved keywords in JavaScript How to support full Unicode in MySQL databases How to speedrun Dropbox’s Dropquest 2012 Unquoted font family names in CSS Unquoted property names / object keys in JavaScript Valid JavaScript variable names in ES5 CSS character escape sequences JavaScript’s internal character encoding: UCS-2 or UTF-16? The smallest possible valid (X)HTML documents JavaScript character escape sequences JavaScript foo.prototype.bar notation Ambiguous ampersands HTML element + attribute notation How I detect and use localStorage: a simple JavaScript pattern Unquoted attribute values in HTML and CSS/JS selectors The end-tag open (ETAGO) delimiter Using the oninput event handler with onkeyup/onkeydown as its fallback Everything you always wanted to know about touch icons In defense of CSS hacks — introducing “safe CSS hacks” AirPlay video support in iOS Safari — a bookmarklet Completing Dropbox’s Dropquest 2011 in 60 seconds Using CSS without HTML How to create simple Mac apps from shell scripts Using setTimeout to speed up window.onload Bulletproof JavaScript benchmarks Thoughts on Safari Reader’s generated HTML How to enable Safari Reader on your site? The XML serialization of HTML5, aka ‘XHTML5’ The id attribute got more classy in HTML5 The three levels of HTML5 usage The HTML5 document.head DOM tree accessor Bulletproof HTML5 <details> fallback using jQuery Displaying hidden elements like <head> using CSS Inline <script> and <style> vs. external .js and .css — what’s the size threshold? Using Showdown/PageDown with and without jQuery
Dear Google, please fix plain text emails in Gmail
Mathias · 2014-07-04 · via Mathias Bynens

By default, composing a new email in Gmail results in an HTML email under the hood — even if you don’t use any formatting. Luckily, it’s possible to opt-out of that and use plain text email instead. In the ‘new email’ window, click the downwards arrow and check ‘Plain text mode’.

Gmail remembers your preference, so any new emails you compose after that are automatically in plain text mode, too.

The problem

Unfortunately, Gmail hard-wraps emails that are composed in plain text mode before sending them. If you would send this message, for example:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

What would actually get sent is the following:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat
volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

Here’s a screenshot of such an email, in Gmail:

And here’s what that same email looks like in another email client (in this case, OS X’s Mail.app):

Instead of filling up the available screen width and letting the text flow naturally, the automatically inserted hard breaks ensure no line is longer than 78 characters. This is especially annoying when viewing such emails on small viewports, e.g. on a smartphone:

Combined with the auto-wrapping due to the small viewport, there are now two lines in the message with just one word on them.

This behavior annoys pretty much anyone who sends plain text emails from the Gmail web client.

Google’s justification

Since I’m a Google Apps for Business customer, I get to file support tickets in hopes of getting issues like these fixed. So I did — I asked whether the hard-wrapping behavior for plain text emails could be disabled. After some painful back-and-forth, this was the response of the Google Enterprise Support team:

The 78 characters per line is not a limitation implemented by Google, but rather an internet standard for plain text messages (RFC 2822) recommended and promoted by the Internet Engineering Task Force (IETF).

It’s true that section 2.1.1 of RFC 2822 recommends a maximum of 78 characters per line (excluding the CRLF newline characters that end each line) in the source of email messages. But if this is what causes the broken behavior in Gmail, how come other mail clients don’t have the same issue? They have to respect the line length limit too, right?

The solution

Sure enough — the problem can be solved without violating any standards and without exceeding the 78-characters-per-line limit. It is perfectly possible to send non-hard-wrapped plain text emails by using the Quoted-Printable encoding as defined by RFC 2045. In fact, Gmail already kind of supports this: it’s capable of decoding and displaying Quoted-Printable-encoded emails flawlessly, and it encodes HTML emails with it before sending them — it just doesn’t do the same thing for plain text emails (yet).

Here’s what the source of a plain text email composed in Gmail looks like. Note that it contains hard line breaks to satisfy the 78-characters-per-line limit:

Content-Type: text/plain; charset=UTF-8	

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat
volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

With Quoted-Printable encoding, it could look like this instead:

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy =
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wi=
si enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lo=
bortis nisl ut aliquip ex ea commodo consequat.

This way, the lines wrap nicely (no forced line breaks) when viewing the email in Gmail or in another mail client.

Summary

Dear Gmail team, please consider Quoted-Printable-encoding plain text emails composed using the Gmail web interface as shown in the above example, just like you do for HTML emails. That way, no hard-wrapping of the email’s actual contents is necessary. Thanks!