pshute wrote:
If the Apple Watch can already handle emails larger than its display, why have they bothered to change the format of ASC emails to accommodate it? I was assuming that if Apple thought it would be a good idea to do this with ASC then they might eventually extend it to emails generated by other means.
I really can't imagine that whoever thought this idea up didn't anticipate trouble. Has this sort of format ever been used elsewhere?
Do we have any stats on how many people are affected by this?
Hello again pshute,
While the Apple Watch can handle large text e-mails, it includes a big warning that some of the content was not displayed. This was probably an effort to avoid that big warning. The warning comes from a completely different division of Apple. Apple likes to promote itself as a company still running with a "startup culture" but don't believe that. It is a huge, international conglomerate. Getting one Apple division to even talk to another one is a major task I'm sure.
You raise a good point about Apple expanding this to other Apple e-mails. But again, we are talking about Apple Support Communities. This is about as back-woods as Apple gets. The rock-stars who work on the iPhone, Watch, or iTunes wouldn't give them the time of day, figuratively speaking of course.
The only people affected by this would be people on Apple Support Communities with 3rd party e-mail clients and perhaps some 3rd party e-mail services. And by affected means just that - nothing is really broken. So it is probably not a huge problem. I can certainly imagine how the problem wouldn't have been anticipated. The problem originated from people that handle significant portions of the world's e-mail traffic. Those people never bothered to implement and test significant ports of the internet e-mail standards that were published a generation ago. So yes, people who work for Apple Support Communities, who don't specialize in e-mail, and don't use those other e-mail providers, didn't check. And again, it really isn't broken either. Maybe they did check but decided that it was better to support the Apple Watch than 3rd party e-mail providers.
A suggestion I've been given elsewhere is "Apple should define and register an Apple-Watch-Summary header field and put it there". Is that a usable solution? Perhaps that requires changes on the Apple Watch as well.
That solution has already been proposed and implemented by Apple. However, considering that 3rd party e-mail providers never bothered to support the e-mail standards of 23 years ago, why would they support the e-mail standards of tomorrow? And the Apple Watch people who implemented this solution also did it wrong. (See http://appleinsider.com/articles/15/05/14/html-parsing-quirk-allows-hidden-email -content-only-viewable-on-apple-watch) Welcome to life on the internet. 🙂
There was also a comment that multipart/alternative parts are supposed to contain versions of the message in increasing order of complexity. In this case, the second part isn't more complex than the first - it's missing some of the text.
It is a syntactic complexity, not a semantic complexity. It is also based on a quirk of the watch being able to read one kind of HTML but not full HTML. It's just a hack. I have submitted a more elegant solution to Apple. Hopefully they will be able to implement it in the near future. Unfortunately, if they now start doing some belated 3rd party testing, I have no doubt that the solution I proposed will have problems too. It still depends on support of the same old standard defined in 1998. I verified with a couple of people on 3rd party services that it works. We just have to wait and see now.
