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

推荐订阅源

Forbes - Security
Forbes - Security
大猫的无限游戏
大猫的无限游戏
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Jina AI
Jina AI
美团技术团队
博客园 - 聂微东
博客园 - 叶小钗
Security Latest
Security Latest
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园_首页
Spread Privacy
Spread Privacy
J
Java Code Geeks
雷峰网
雷峰网
宝玉的分享
宝玉的分享
C
Cyber Attacks, Cyber Crime and Cyber Security
P
Privacy International News Feed
C
CXSECURITY Database RSS Feed - CXSecurity.com
T
Threat Research - Cisco Blogs
The Hacker News
The Hacker News
量子位
L
LINUX DO - 热门话题
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
G
GRAHAM CLULEY
D
Darknet – Hacking Tools, Hacker News & Cyber Security
月光博客
月光博客
腾讯CDC
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
酷 壳 – CoolShell
酷 壳 – CoolShell
T
Tor Project blog
罗磊的独立博客
V
Vulnerabilities – Threatpost
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
有赞技术团队
有赞技术团队
Project Zero
Project Zero
Hugging Face - Blog
Hugging Face - Blog
爱范儿
爱范儿
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
T
Tenable Blog
MyScale Blog
MyScale Blog
T
The Exploit Database - CXSecurity.com
GbyAI
GbyAI
博客园 - 【当耐特】
O
OpenAI News
Schneier on Security
Schneier on Security
S
Secure Thoughts
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
S
Securelist
博客园 - 司徒正美

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!