~soywod/pimalaya#210: 
mml/himalaya: Plain text part is shown before html text part in iOS mail

Hi guys,

I just happened to notice that when you use this mml example with Himalaya, in iOS Mail both parts—text/plain and text/html—are visible. Other email programs display this correctly, i.e. only the text/html part.

This may be an Apple issue in the first place; yet, this does not happen with other multipart emails I receive in iOS mail, e.g. newsletters. That's why I'm mentioning this here.

Tested with iOS 15.8.2 and iPadOS 16.6.1

Thanks!

Status
REPORTED
Submitter
~neff
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

~soywod a month ago

Hey,

I just happened to notice that when you use this [mml example] with Himalaya, in iOS Mail both parts—text/plain and text/html—are visible. Other email programs display this correctly, i.e. only the text/html part.

In fact Apple is right, the example you are refering to produces a "multipart/mixed" part composed of 3 subparts: "text/plain", "text/html" and an image. They should all be displayed in theory.

If you want to let clients show either the plain or the HTML, then you need to explicitly wrap them into a "multipart/alternative" part:

In practice, when a client sees a plain with a HTML part (no matter the multipart type), it acts like a "multipart/alternative" and chose the one the most suitable.

Nothing we can do about it, except maybe to rename examples to make them more explicit?

-- Regards Clément DOUIN https://soywod.me

~neff a month ago

Thank you very much. I've got it now ;-)

Nothing we can do about it, except maybe to rename examples to make them more explicit?

Maybe, we can add a simple example named multipart.eml?

<#multipart type=alternative>
The MUA that will read this email will choose between this text/plain part…

<#part type=text/html>
<p>…and this HTML part</p>
<#/part>
<#/multipart>

In fact, I made two mistakes playing with your excellent software: I forgot multipart and I added some empty lines.

The template

<#multipart type=alternative>

The MUA that will read this email will choose between this text/plain part…

<#part type=text/html>

<p>…and this HTML part</p>

<#/part>

<#/multipart>

produces

text/plain
text/html
text/plain (empty)

and some MUAs (including Apple Mail) only show the empty text/plain part here.

Maybe it could also be documented where empty lines are allowed within MML?

And thanks again for this project. Himalaya + MML is an excellent way to write e.g. HTML newsletters with plain text fallback.

~soywod a month ago

Maybe, we can add a simple example named multipart.eml?

Definitely. Let's keep the issue open for this purpose!

In fact, I made two mistakes playing with your excellent software: I forgot multipart and I added some empty lines.

The template […] produces:

text/plain text/html text/plain (empty)

Maybe it could also be documented where empty lines are allowed within MML?

Not sure about this behaviour. I remember that I deliberately accepted this trade off, so users have better control, but now I doubt. It does not make sense to compile empty parts, but this implies to "modify" the user choice. What do you think? Should we accept or deny empty parts? Should it be customizable with an option?

Meanwhile I will do some tests with the original Emacs MML module to see how it behaves in this particular case.

And thanks again for this project. Himalaya + MML is an excellent way to write e.g. HTML newsletters with plain text fallback.

I'm glad to hear that! I rarely get feedback about MML, so feel free to do so :)

I got an idea once: to support markdown parts. They could be automatically compiled into a multipart alternative composed of one plain version of the markdown and one HTML version of the markdown. It could be even more useful for newsletters.

-- Regards Clément DOUIN https://soywod.me

~neff a month ago

Hi,

Definitely. Let's keep the issue open for this purpose!

👍

What do you think? Should we accept or deny empty parts? Should it be customizable with an option?

Thanks for asking; but actually I am not familiar enough with email formats. So I have no idea whether there is a use case for empty parts at all.

Writing MML by hand would probably be more intuitive if empty lines around the actual content—i.e. empty lines after <#[multi]part …> and before <#/[multi]part> would just be ignored. So the following examples would render equally.

<#multipart type=alternative>
The MUA that will read this email will choose between this text/plain part…
<#part type=text/html>
<p>…and this HTML part</p>
<#/part>
<#/multipart>
<#multipart type=alternative>


The MUA that will read this email will choose between this text/plain part…


<#part type=text/html>


<p>…and this HTML part</p>


<#/part>


<#/multipart>

I got an idea once: to support markdown parts. They could be automatically compiled into a multipart alternative composed of one plain version of the markdown and one HTML version of the markdown. It could be even more useful for newsletters.

This would be perfect and a great addition.

Currenty, I just write simple HTML or copy markdown—or djot—generated HTML. Your markdown suggestion would simplify this a lot.

For complex newsletter layouts I use mjml to generate the HTML part.

Thanks a lot!

~soywod a month ago

Writing MML by hand would probably be more intuitive if empty lines around the actual content—i.e. empty lines after <#[multi]part …> and before <#/[multi]part> would just be ignored.

The problem is that you break the layout the user tried to set up. Let say you have the following:

Here an attachment:

<#part filename=./attachment.jpeg disposition=attachment><#/part>

Hope you will get it!

By trimming empty lines and white spaces before and after parts, client may just display:

Here an attachment:Hope you will get it!

Actually the lib displays:

Here an attachment:

Hope you will get it!

which seems closer to what the user really wanted to send.

Not sure how to properly deal with it.

-- Regards Clément DOUIN https://soywod.me

Register here or Log in to comment, or comment via email.