#511 accepted
Josh Dick

Inline HTML in Markdown

Reported by Josh Dick | November 27th, 2013 @ 10:49 PM

I write this with the full understanding that this might possibly be a duplicate of #197, but I wanted to err on the side of creating a new ticket. :)

Markdown allows for inline HTML, but MailMate appears to clobber inline HTML when it is mixed side-by-side with Markdown. I understand from experimenting that MailMate won't attempt to parse input as Markdown unless it includes Markdown syntax characters. So, until I add something like *bold syntax* to a message, any inline HTML elsewhere in the input is rendered in the preview as plain text, which makes sense.

Adding the *bold syntax* (for example) at the bottom of the message will turn on Markdown parsing, at which point any inline HTML is no longer rendered as plain text in the preview, but doesn't appear to always be rendered as expected, either. For example, I tried using <table> tags in the message body as an experiment, but no <table> tags appeared in the generated output.

Is this expected behavior?

Comments and changes to this ticket

  • benny

    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.

  • Josh Dick

    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!

  • andrew cates
  • Rob Tull

    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

    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.

  • Peter Mienes

    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 .

  • Anthony Craig

    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

    benny January 24th, 2019 @ 12:24 PM

    Re: [MailMate #511] Inline HTML in Markdown

  • Mike K

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

    Just chiming in here... After years of privately bristling at being unable to format outgoing emails in standard, sensible ways (markdown isn't that by a country mile), unfortunately, my biggest client has mandated the use of colored text in email replies to differentiate my replies from their comments. After all this time (including a lot of sporadic whining and cadging and complaining from myself, which Benny has graciously put up with for years) MailMate finally really has, for the last year or two, finally gotten to where it does 99% of what a full-featured email client needs to (and then some. It would be unfair to say that without mentioning that in some features, MailMate obviously excels far, far beyond anything else... and cheers for that.) But a few glaring limitations remain, and now a decision about them has been made for me.

    Unfortunately in the real world, no programming perspective about the technical problems of using HTML in emails is going to matter to the users out there in the marketplace who I need to correspond with. If I tell them I can't respond with color, that makes me look bad—all they know is that they've been getting emails containing colored text for 25 years. I need to be able to tell my clients "Yes, I can do exactly what your business needs me to."

    I came to the forum today in hopes that I'd find that somewhere along the way, this feature had been added. Darn. Any chance we'll see this soon?

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

Attachments

Referenced by

Pages