Freron MailMate

Comments and changes to this ticket

• 

  benny November 28th, 2013 @ 10:00 AM

  • State changed from “new” to “accepted”

  Yes, this is expected behavior. MailMate does not currently allow inline HTML in Markdown. The reason for this is that MailMate would have to put this HTML verbatim in the plain text body part of the message. This is perhaps better explained here (different problem, but the same reason).

  I might remove this restriction and therefore I'll put this ticket in an “accepted” state, but to be honest I'm not yet quite sure how to handle this. The obvious approaches are:

  • Just put verbatim HTML in the plain text body part.
  • Convert HTML to text in the plain text body part.

  The first solution is easier and even though some recipients can only handle plain text messages then it might still be better than the second solution. The main problem might be that I really don't want to encourage the use of inline HTML.

• You flagged this item as spam.
  

  Josh Dick November 28th, 2013 @ 06:26 PM

  From #184:

  My general opinion is that HTML is a very bad format for composing emails and there exists no standardization in this area. It really only works well for one-way marketing emails (if the receivers are known to use HTML capable email clients).

  And from above:

  The main problem might be that I really don't want to encourage the use of inline HTML.

  With the utmost respect...why? :)

  I agree that the current ecosystem around HTML in e-mail is a complete mess and no solution is going to be optimal, but it really the responsibility of an e-mail client to [dis]allow the use of HTML either way (regardless of whether rich editing controls are involved)?

  It seems to me that claiming support for Markdown but treating elements of Markdown in unexpected ways is confusing at best and misleading at worst, and leads to questions like mine and the numbered-list thread you linked to above.

  The split body part problem mentioned above and in the numbered-list thread is an interesting one. If it were up to me to solve it, I'd probably keep it as simple as possible:

  • For the plain text body part, send the user's input verbatim/unmodified. Users are supposed to be typing valid Markdown in the input box if Markdown is enabled--inline HTML/out-of-order numbered lists and all--so I don't think sending the text verbatim would be an unreasonable or unexpected behavior.
  • For the HTML body part, generate the HTML from the Markdown using as compliant a parser as possible, which would respect inline HTML, reorder numbered lists, etc.

  This seems simplest to me, both for implementation as well as behavior expected by users; what will be sent is exactly what the user sees on the screen, both in plain text and HTML.

  Thanks for your hard work on MailMate, and for considering requests like this/keeping a dialog going!

• You flagged this item as spam.
  

  andrew cates January 5th, 2014 @ 05:38 AM

  +1

• You flagged this item as spam.
  

  Rob Tull February 18th, 2014 @ 03:42 PM

  I would like to add some thoughts on how this could be tackled. I do have a need for HTML occasionally when sending emails that need a degree of emphasis or focus I find difficult with only Markdown. It's a reality I can't seem to escape. However, I also don't like the idea of HTML in email generally. I would propose the following, in line with some of the above comments:

  1. Disable direct HTML by default. This will discourage folks from doing it. Force a hidden preference change if they want to use HTML that badly.
     
  2. Put it in the text copy verbatim. This will discourage people from going too crazy with their HTML tags. And I think it can be expected given everything else about MailMate.

  What this will do, I believe, is simultaneously discourage overuse of HTML and yet still make it available for those cases where you really need it. Since it will have to be specifically enabled (hidden pref is fine), and it will be exposed in plain text, and you will have to know enough HTML to write it by hand, I think that overuse will be minimal.

  Note: I also agree with the comments about parsing Markdown in a more typical fashion. I write Markdown for everything whenever I can and having to remember different Markdown behavior from one app to another starts to break the intent of using Markdown, in my opinion.

• 

  benny February 19th, 2014 @ 12:59 PM

  @Tull: Thanks for your thoughts on the subject. I'll keep them in mind (and I do mean that). With respect to “typical” Markdown, it's not as simple as it sounds. I have to make sure that the plain text body part (currently the raw Markdown) behaves “nicely”, for example, the line break tradition of Markdown does not work well for emails.

• You flagged this item as spam.
  

  Peter Mienes March 23rd, 2015 @ 09:36 AM

  I think this is the same issue:
  I received an email with a numbered list. When replying to it, MailMate just concatenates all numbered items (without numbers though), so the structure of the original mail is lost, and in my reply I have to put the numbers manually in the original text to bring back some of the structure again. This is especially annoying when the numbers of the numbered list are referred to later in the original mail, e.g. Ad.1, Ad.3 .

• You flagged this item as spam.
  

  Anthony Craig January 23rd, 2019 @ 02:31 PM

  What's the status on this, Benny? Think you can include inline HTML within Markdown composing? It would surely be useful sometimes :)

• 

  benny January 24th, 2019 @ 12:24 PM

  Re: [MailMate #511] Inline HTML in Markdown

  • untitled 1.1 KB

• You flagged this item as spam.
  

  Mike K March 13th, 2020 @ 10:35 PM

  .