2 comments

[ 0.25 ms ] story [ 15.1 ms ] thread
One of our customers noticed that Apple were sending a special mime type that the Watch would pick as the default when rendering an email.
Cool find, OP!

> the Watch will only fall back to your watch-html part if there’s something unsuitable in the standard HTML part. A simple remote image, such as a tracking bug or a hidden image, will do the trick.

> This technique works because the Apple Watch will try the text/html part, then gradually work its way back up through the MIME parts, looking for suitable content. While we’ve named our Content-Type “text/watch-html”, it could, in reality, be called anything beginning with “text/”.

> you must ensure the Watch HTML part appears before the standard HTML part in your email source, and after the plain text part. If you include the Watch HTML elsewhere, Apple Mail on the desktop will render your Watch HTML as plain text.

The order issues make sense given RFC 1341 7.2.3[0] on preferred-format ordering. There might be more to the Watch's behavior, that the article authors haven't discovered yet. How and why does the Watch/iPhone decide to interpret something tagged as 'text/*' as HTML? Apple Mail sounds like it's doing the right thing, and the Watch is doing something wrong. There should probably be a dedicated MIME type that means "HTML for a Watch", or maybe some other property on a part with type text/html. What Apple have done seems likely to have unintended results for somebody out there, when their actual plain text gets rendered as HTML. I hope it's not as standards-noncompliant as it seems.

[0] http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html