4 ms·

Given that email is MIME (i.e. you can add multiple “bodies” to a message, with different content-types, and the email client will select the best one it can re

by derefr 5y ago

Given that email is MIME (i.e. you can add multiple “bodies” to a message, with different content-types, and the email client will select the best one it can render), you’d think we could just come up with a new content-type for email meaning “HTML, but for real”, and add that to email in addition to the current “HTML, but sucky” semantics we get from text/html-typed bodies. For a while, people would be sending both text/html and text/html-for-real, but eventually we’d maybe be able to switch to only sending text/html-for-real (while also continuing to send text/plain for fallback.)

blacksmith_tb 5y ago
CSS grid email designs would be great, but we'd also get an avalanche of nightmare canvas-tag spam...
- toastal 5y ago
  Maybe more people will then demand plaintext as we come full circle
- ratww 5y ago
  You can have one without another! Apple Mail supports grid, but doesn’t support canvas or script tags.
- akx 5y ago
  A canvas tag won't do much without scripts, and I really don't believe any client would allow running scripts from email...
smichel17 5y ago
I wish people sent text/plain as a fallback for text/html...
drewzero1 5y ago
> a new content-type for email meaning “HTML, but for real” text/email Mozilla/5.0 (KHTML, like Gecko)
- derefr 5y ago
  I get what you mean, but it's not like we'd have to keep adding these on. "text/html" on email clients currently means "some specific ossified version of HTML4"; but text/html-for-real would hopefully mean "the newest and most featureful version of HTML that your rendering engine can manage." So there'd just be the one version of it. Eventually, if everybody switched to sending text/html-for-real first, maybe the email clients could follow along and make text/html also mean "the newest and most featureful version of HTML5"; and then we could all revert to just calling it text/html. Rather than a distinct MIME type, I believe it could also make sense to borrow the HTTP header X-Content-Type-Options: nosniff (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...) into the MIME envelope of the text/html document, to signal that this envelope is "really" using HTML, no second-guessing. (This is how the header was used in IE8: to tell the renderer to explicitly not trigger IE historical-renderer compat mode.) That might get into a situation where the message has two MIME bodies that are both text/html, though, and I'm not sure existing clients have been written to cope with that. A well-engineered solution would work with existing clients (by having them ignore the body of unknown-to-them media-type, and render the old fallback body of known media-type.)

by derefr 5y ago

blacksmith_tb 5y ago

CSS grid email designs would be great, but we'd also get an avalanche of nightmare canvas-tag spam...

toastal 5y ago
Maybe more people will then demand plaintext as we come full circle
ratww 5y ago
You can have one without another! Apple Mail supports grid, but doesn’t support canvas or script tags.
akx 5y ago
A canvas tag won't do much without scripts, and I really don't believe any client would allow running scripts from email...

smichel17 5y ago

I wish people sent text/plain as a fallback for text/html...

drewzero1 5y ago

> a new content-type for email meaning “HTML, but for real” text/email Mozilla/5.0 (KHTML, like Gecko)

derefr 5y ago
I get what you mean, but it's not like we'd have to keep adding these on. "text/html" on email clients currently means "some specific ossified version of HTML4"; but text/html-for-real would hopefully mean "the newest and most featureful version of HTML that your rendering engine can manage." So there'd just be the one version of it. Eventually, if everybody switched to sending text/html-for-real first, maybe the email clients could follow along and make text/html also mean "the newest and most featureful version of HTML5"; and then we could all revert to just calling it text/html. Rather than a distinct MIME type, I believe it could also make sense to borrow the HTTP header X-Content-Type-Options: nosniff (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...) into the MIME envelope of the text/html document, to signal that this envelope is "really" using HTML, no second-guessing. (This is how the header was used in IE8: to tell the renderer to explicitly not trigger IE historical-renderer compat mode.) That might get into a situation where the message has two MIME bodies that are both text/html, though, and I'm not sure existing clients have been written to cope with that. A well-engineered solution would work with existing clients (by having them ignore the body of unknown-to-them media-type, and render the old fallback body of known media-type.)