[MlMt] Do we need a better way to disable text/not-really-plain?

[Rob McBroom]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20140116/350cb3e7/attachment-0001.html>