On 15 Jan 2014, at 15:02, Bill Cole wrote:
Which is why MM generates a multipart/alternative message with
text/plain and text/html parts when one enables Markdown.
True, I had forgotten about that, but the sender can omit the HTML part
without turning of Markdown, as Benny said.
Most critical is URLs. If I wanted URLs automatically hidden from me,
I wouldn't have MM set to prefer plain text and maybe I wouldn't be
using MM at all. I'm a bit disappointed that they are made active
(i.e. "clickable") without any clear way to turn that off, but I am
well-trained to avoid the habits that make that really risky
Something that might help is a custom style sheet that makes links
really stand out. (I forget what they look like by default.)
(OTOH, if something evil grabbed control of the ability to send
keystrokes with 'Full Keyboard Access' enabled...)
Clicking links in e-mail would be the least of my worries in that
situation. :-)
I can only speak for myself, but I think the implementation is great.
Plain text is easier to write, nearly universally portable, and uses
less bandwidth, but (rendered) HTML is much nicer to *read*. So
it’s the best of both worlds.
That's a very subjective judgment
I was clearly trying to pass it off as objective truth when I said “I
can only speak for myself”.
with an embedded fallacy behind the conclusion. Because any reasonable
HTML mail composer creates a multipart/alternative container for the
HTML version of the message and a plain text equivalent, the fact that
you happen to compose in Markdown (which gets used as the plain text
version) uses more bandwidth than if you were to use something that
sent pure HTML.
Absolutely right. Like I said, I had forgotten about the optional HTML
part that gets sent along with the Markdown. I have it enabled, since
most of the people I deal with are using Outlook.
The only thing I would change is that switching to the plain text
alternative should show the original Markdown as written. If that
were the case, I think the “Prefer plain text” Viewer preference
would make MailMate behave the way you want.
No, it does not. If it did, I would not be bringing this up.
I’m aware of that. I thought it obvious that I was describing desired
behavior, not current behavior.
I'm not really open to arguments that I shouldn't want message parts
labeled as plain text to be displayed as plainly as possible rather
than parsed for markup.
You’re not getting one. Not from me, anyway.
This is exactly the “desired behavior” I laid out. When viewing the
plain-text part (whether by default with “Prefer plain text” or by
⌥⌘[), there shouldn’t be any parsing.
(In the case where there is *only* a text part, and it’s identified as
Markdown in the `Content-type` header, clients that support automatic
rendering should behave as if there are two parts. That would allow us
to switch between the two representations and/or see the preferred one
by default.)
I will spare you the arguments for why HTML email is fundamentally
wrong and dangerous.
I know them. I used to make them. But when it became clear that some
sort of “rich” e-mail was here to stay, and MS-TNEF was one of the
more common ways to do it, HTML seemed pretty good all of a sudden.
--
Rob McBroom
http://www.skurfer.com/
_______________________________________________
mailmate mailing list
[email protected]
http://lists.freron.com/listinfo/mailmate
