[MlMt] Show HTML source doing The Wrong Thing

[Benny Kjær Nielsen]

On 6 Dec 2012, at 20:10, Seebs wrote:

>> One possible solution: The “Show HTML Source” menu item is 
>> removed. Instead it is an alternative menu item shown instead of 
>> “Show Raw Message” when holding down ⌃, that is, the shortcut 
>> becomes ⌃⌥⌘U.

[...]

> I guess there IS a case where "show HTML source" would be useful for 
> plain text. But it might also make sense to distinguish, and to 
> consider that a distinct option from "show HTML source" for an HTML 
> part.

Note that “Show HTML Source” always shows the HTML source generated 
by MailMate. That may in some cases be the HTML part of a message, but 
that is not the (original) point of this option. The point was to make 
it possible for the user to see the HTML of whatever is displayed in the 
message view (even if it's the HTML wrapper for a raw message).

> Maybe when looking at text parts, it could be named "Show MailMate 
> HTML wrapper" or something similar, to indicate that we are talking, 
> not about the HTML in the message, but about the HTML mailmate's using 
> to render it.

Yes, I can (now) also see why this option is so confusing. I implemented 
it with a difference purpose than what it is actually useful for (for 
most users).

When I want to see the HTML (or plain text) part of a message then I use 
⌥⌘] / ⌥⌘[.

>> Opinions?
>
> Well, now that I know about the custom style sheet option, I can see a 
> benefit to this. I think the main thing is, it probably wants to be 
> less-visible than "show HTML". If anything, I think it might maker 
> sense to make HTML/text toggles more obvious and more visible; for 
> instance, something in the header-display area that is only present 
> when a message has alternatives, so there could be a little button 
> which appears and says (Show HTML) or (Show Plain Text).

Yes, some kind of HTML indications and buttons have been on my todo for 
a long time. It's one of many things postponed until after I refactor 
the message headers view.

> Right now, if I'm looking at text (or the lack of any text), the only 
> way for me to tell that there might be more (or less) data in the HTML 
> is to go to the View menu, then select the never-greyed-out "Message 
> Body Parts" submenu, and look to see what it shows. I am not sure I 
> have ever seen a message with more than two alternatives for its 
> message body... So providing a visible indicator of "there is probably 
> something else to see" might make sense.

Agreed.

> As might an option for "show text part by preference, unless text part 
> is completely empty and HTML part isn't".

That could possibly just be done by default. Only security-obsessed 
people would have a problem with this and they need an option to simply 
never show HTML (even when it's the only body part). That's another item 
on the todo.

But that still won't solve the cases where the plain text body part is 
some kind of fixed “no plain text available” text.

> So thinking about it:
>
> 1. Would like a "show all headers" distinct from "show entire message 
> completely raw".

I assume you mean formatted/decoded headers. That might not be too hard 
to do while still providing the functionality of the current headers 
view (links and menus). But again, I've planned a complete rewrite of 
the headers view which means I'm reluctant with regard to doing too much 
with the existing view :-)

> 2. Maybe "show HTML source" should turn into "show unprocessed body", 
> wherein HTML is rendered as source, and quoted-printable (which is odd 
> because everything I've heard people say about it is unprintable) gets 
> shown still-mangled, for instance. Possibly even base64 crud. :)

Isn't that what you get with “Show Raw Message”?

> 3. An option for "show the HTML wrapping MailMate is doing to this 
> text" is useful, but should probably not be in the same category as 
> "show the source of this HTML message".

Agreed. I need to make it less prominent while making it easier to do 
“Show HTML Body Part” (a HTML button of some sort would probably 
solve most user problems).

> 4. The more I interact with this program, the more amazed I am that 
> anyone has ever successfully written a mail client, because every time 
> I suggest something that sounds simple it turns out to be a fairly 
> complex territory that I had never been aware of.

I could probably write a book about it by now ;-)

-- 
Benny