Tickets :: Comment on [#10235] Email attachments on printed emails

* Your Email Address
* Spam protection	Enter the letters below: ._..___. ..___.__ \| [__ \|__\|[__ \| \ _\|_\| \| \|\| \|__/
Comment	>> Please don't simply revert while we're still discussing this. It's >> not like this breaks anything. > > Not to sound like a jerk - but I had originally rejected this. You > overruled that decision and committed this. Reverting is entirely > appropriate. We need to stay at the status quo - only until we decide > whether we want should we add if necessary > >> I don't buy your argument why we might include the basic headers but >> not the attachment list. >> 1) It's important, or at least useful, information about a message. >> Not printing those anymore is a regression from IMP 4. > > I had a long discussion about this when we implemented the IFRAME > HTML rendering. It really comes down to this: > > * You correctly render HTML parts. > vs. > * You can print the entire message. > > At this point, you MUST choose one or the other. In the past, HTML > mails weren't as prevalent as they are today. Not to mention are > rendering code and filtering code weren't all that great. > > But now, I would say that text/html has pretty much become the > defacto standard. So viewing is more important than printing. > > Sometimes you have to make tough decisions. Yes, it is a regression > with respect to printing messages. But it is a vast leap forward in > the more common use case of viewing an HTML part. So I stand by this > decision. > >> 2) It's unobtrusive and won't affect many messages (probably depends >> on how often you get messages with attachments. But then again, how >> often do you actually print messages?) > > But going back to my original point: why is this attachment list > important? How can it possibly be important to have an attachment > list when you are only printing (and caring about) a single part? > When I print the portion of the message that contains the map to > Grandma's house, I don't care that she also attached pictures of the > cats that are going to be there to greet me when I arrive. This is > worthless information, and cuts into the printable space available on > that first page. > >> I understand the technical limitations that still keep us from >> printing all parts, and I don't have a smart solution for this. But >> limitations of browsers should not keep us from providing us better >> experience for the users. Actually the opposite, we need to provide >> users with alternative solutions if something is limiting them. > > Possible solutions: print as PDF; popup print screens reload after > every printable part to load the next printable part while calling > window.print() on each one. > >> The crucial point is that currently the user is not able to print the >> whole message if it consists of multiple parts. But they don't care >> and will print messages anyway. In 95% (if not more) of the messages, >> there will be one single printable message part. Users don't care if >> they are looking at a multipart message. They are happy that their >> message will be printed (and without even knowing about that, that >> your worked around IFRAME printing browser bugs). They don't care >> that it's only one part of the message, because that's probably the >> only part they see inline anyway. Heck, the printout even has the >> message headers, they won't even notice. All that's missing is, >> gotcha, the attachments summary they had in their old version. > > These are all arguments for the creation of a feature to allow > printing of an entire message. But NONE of these arguments are > applicable to what we currently have available: printing of a single > message part. > > We can't be mixing UI elements/features just because we are lacking > functionality. I have spent a long time in IMP 5 to remove these > kind of decisions we made in the past - feature bloat if you will. > Instead we need to focus on the UI as CURRENTLY implemented (not how > we would LIKE it to be implemented). > > As I have said multiple times in this ticket, having an attachment > list doesn't make any sense when you look at what this UI element is > intended to do: print a specific message part. So this patch is not > appropriate.
Attachment
Watch this ticket

Saved Queries