Tickets :: Comment on [#7981] No way to get some attachments to a multipart message

* Your Email Address
* Spam protection	Enter the letters below: . ..___\ /.__. . \| \|[__ >< \| \| \| \|__\|[___/ \\|__\|\__\|
Comment	>> I think we are talking about 2 separate issues here. Issue 1 is how > >> to display (alleged) attachments that are not ordinarily displayable > >> in a MIME message. Two examples would be parts of a > >> multipart/related message that are not linked in the base message and > >> multipart/alternative parts that are not displayable in the browser > >> (which, as it turns out, is not the present issue - see below). In > >> both cases, for exactly the usability reasons discussed below, these > >> parts CAN NOT be displayed inline as attachments unless attachment > >> inline viewing is turned on. Doing so means that there is no longer > >> multipart/related or multipart/alternative messages - we just display > >> everything as multipart/mixed. This can not be the case. > > > > Agreed. > > > >> e.g. For multipart/alternative parts, displaying the "alternative > >> parts" box was a usability nightmare also so that should not be > >> brought back. Especially in light of this mandate from the RFC: > >> "What is most critical, however, is that the user not automatically > >> be shown multiple versions of the same data." > > > > Also agreed. > > > >> The 2nd issue is simpler: tweaking the display of > >> multipart/alternative parts. That is the present case. The MIME > >> structure here is as follows: > >> > >> multipart/alternative > >> text/plain > >> multipart/mixed > >> test/html > >> application/vnd.ms-excel > >> test/html > >> > >> This oh-so-unenlightening remark from RFC 2046 [5.1.4] is the key: > >> > >> In the case where one of the > >> alternatives is itself of type "multipart" and contains unrecognized > >> sub-parts, the user agent may choose either to show that alternative, > >> an earlier alternative, or both. > >> > >> So the RFC tells us nothing in this situation. Useful. Displaying > >> both is just bad usability IMHO. > > > > I'm not sure it is. Looking at the message structure, you have text > vs. mixed. So if we can display mixed, and we can, seems like we > should just treat the message as though it were html - excel - html. > The entire 3-part string is the alternative - they aren't > alternatives for each other. > > > >> Finally, my rant: This message does nothing to alter my view of > >> Mail.app (and it's not just me - if you want to see some real > >> Mail.app bashing, read the dovecot list sometime). This message > >> apparently assumes that the receiving user is on a desktop-ish > >> machine - it seems as though the message wants the spreadsheet > >> attachment to be living in the middle of the HTML part. This display > >> tactic may work on a desktop machine, where one can display a little > >> spreadsheet icon a user can click/drag-drop/etc., but is not > >> practical on something like webmail. > > > > Actually, why can't we put a download icon there? We might not want > to, and the code for it might be ugly, but technically it's possible. > > > >> clients that can't generate this kind of UI (webmail, > >> pine/alpine/elm) will be an HTML part, a link to download the > >> spreadsheet attachment, and then another HTML part that is > >> completely empty of content. With that last part: how is that not a > >> usability nightmare? I can imagine a bunch of users complaining why > >> they are being shown a part with no content and/or why the software > >> is broken and not showing the correct contents of that part. > > > > This is why it's not necessarily great usability to flag for the user > each different part of the message. If we don't call out each part, > but display what we can and provide download links for the rest, then > the user doesn't have to know there's an empty part. There might > just be a little extra space at the end of the message. But they > don't need to care about it, because the UI doesn't have to make it > obvious. > > > > In the end, as long as we can do something where I get a download > link for the spreadsheet in this message, without having to turn on > the full parts list (which I don't think is a user-friendly thing, > but that's a separate issue perhaps), then I'm happy. > > > > Thanks for working through this.
Attachment
Watch this ticket

Saved Queries