There's a question according to http://trac.roundcube.net/ticket/1488783.
There are messages with related images. Normally, they are referenced in HTML bodies (parts), but not always. So, the question is: should we list such attachments on attachments list. We have a few possibilities:
- Do not list any in text and html mode (current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only
(Thunderbird's way). 4. List all in text and html mode (only for completenes, I suppose we shouldn't ever choose this option).
Implementing this as a user preference will be overcomplicated, we don't want to make it optional, we should choose one. So, what's your opinion?
For now I have no strong opinion, but I'm somewhere between 1. and 2.
On 21.03.2013 19:11, A.L.E.C wrote:
There's a question according to http://trac.roundcube.net/ticket/1488783.
There are messages with related images. Normally, they are referenced in HTML bodies (parts), but not always.
Are we talking about these: "To protect your privacy, remote images are blocked in this message."? So related = remote?
If so:
- Do not list any in text and html mode (current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only
(Thunderbird's way). 4. List all in text and html mode (only for completenes, I suppose we shouldn't ever choose this option).
As we should also give the text oriented users the opportunity to get access to those pics, I'd vote for 3 (Thunderbird).
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 03/21/2013 10:17 PM, Michael Heydekamp wrote:
There are messages with related images. Normally, they are referenced in HTML bodies (parts), but not always.
Are we talking about these: "To protect your privacy, remote images are blocked in this message."? So related = remote?
It's not about remote images. It's about attached images. And this attachments don't even need to be images, but in most cases they are images.
As we should also give the text oriented users the opportunity to get access to those pics, I'd vote for 3 (Thunderbird).
Of course we'll not handle remote images this way.
Am 22.03.2013 08:40, schrieb A.L.E.C:
On 03/21/2013 10:17 PM, Michael Heydekamp wrote:
There are messages with related images. Normally, they are referenced in HTML bodies (parts), but not always.
Are we talking about these: "To protect your privacy, remote images are blocked in this message."? So related = remote?
It's not about remote images. It's about attached images.
I wasn't sure what the term "related images" exactly means. Attached images is clear to me, but what's the difference to related images?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 03/22/2013 07:13 PM, Michael Heydekamp wrote:
I wasn't sure what the term "related images" exactly means. Attached images is clear to me, but what's the difference to related images?
Images used inside HTML code referred by attachment Content-Id. It might be <img src="cid:1234">. Such images are a message parts inside multipart/related structure of the message. Sometimes such attachments do not have a reference in HTML body, I call them unreferred.
So, we do not talk about attachment parts of multipart/mixed message, they aren't related with any part.
Am 22.03.2013 19:38, schrieb A.L.E.C:
On 03/22/2013 07:13 PM, Michael Heydekamp wrote:
I wasn't sure what the term "related images" exactly means. Attached images is clear to me, but what's the difference to related images?
Images used inside HTML code referred by attachment Content-Id. It might be <img src="cid:1234">. Such images are a message parts inside multipart/related structure of the message. Sometimes such attachments do not have a reference in HTML body, I call them unreferred.
related, referred, unreferred ... I must admit that I'm not too familiar with this complex HTML stuff in connection with multipart/related messages. What's the (technical) difference, if an image is referred to in a HTML body or not?
For now, I share the position of Sébastien BLAISOT:
Those images should be accessible for download in HTML and text mode, no matter if referred or unreferred (unless there is a sound technical reason for it, which I'm not aware of).
So I'd still vote for 3. (still not being sure of all of its implications).
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 03/22/2013 11:54 PM, Michael Heydekamp wrote:
related, referred, unreferred ... I must admit that I'm not too familiar with this complex HTML stuff in connection with multipart/related messages. What's the (technical) difference, if an image is referred to in a HTML body or not?
I'll not explain what multipart/related is, sorry.
Those images should be accessible for download in HTML and text mode, no matter if referred or unreferred (unless there is a sound technical reason for it, which I'm not aware of).
Did you ever see a web page with images? They can be everywhere in header, in footer, they can be set as a background, buttons, etc.. So, these images in email are attached to the message (or are external links, but we're not talking about this case). Now, when you convert such a HTML content into plain text, are you sure you want to see all of these images on the attachments list (or displayed after body)? Even these background images or icons, etc?
Le 23/03/2013 07:53, A.L.E.C a écrit :
Those images should be accessible for download in HTML and text mode, no matter if referred or unreferred (unless there is a sound technical reason for it, which I'm not aware of).
Did you ever see a web page with images? They can be everywhere in header, in footer, they can be set as a background, buttons, etc.. So, these images in email are attached to the message (or are external links, but we're not talking about this case). Now, when you convert such a HTML content into plain text, are you sure you want to see all of these images on the attachments list (or displayed after body)? Even these background images or icons, etc?
Yes Sir ! I'm sure and absolutely sure that it is better to see all of these images in the attachement list than hidding them totally to the user. (maybe you can order attachements between real attachements, inline unrefered and then inline refered)
A lot of people who write html mail with images, backgrounds, and so on, tend to use images with meaningful content and without alternative text. This way, reading their mail in text mode, you loose information. The only way to get this information back is to :
- Show in text mode that there were an image here
- Let the user show the image
This way, if it thinks I'm loosing something, it can verify by viewing the attached image.
and an exemple :
"here is the image I want you use for my new website : "
If you don't show html embedded images in text mode, you have no mean to retrieve this image in text mode (and you cannot build my new website, so I will not pay you for this :-) ).
regards,
S.B.
Am 23.03.2013 07:53, schrieb A.L.E.C:
So, these images in email are attached to the message (or are external links, but we're not talking about this case). Now, when you convert such a HTML content into plain text, are you sure you want to see all of these images on the attachments list (or displayed after body)? Even these background images or icons, etc?
Sure.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Le 22/03/2013 23:54, Michael Heydekamp a écrit :
For now, I share the position of Sébastien BLAISOT:
Those images should be accessible for download in HTML and text mode, no matter if referred or unreferred (unless there is a sound technical reason for it, which I'm not aware of).
humm, this is not exactly what I said. Images should be available for download (ie. in the attachemlent list) in text mode. But in HTML mode, they are displayed inline, they don't need to be in the attachement list (as I can right click -> save the image in my browser)
So I'd still vote for 3. (still not being sure of all of its implications).
but we come to the same conclusion :=)
Am 23.03.2013 10:32, schrieb Sébastien BLAISOT:
Le 22/03/2013 23:54, Michael Heydekamp a écrit :
For now, I share the position of Sébastien BLAISOT:
Those images should be accessible for download in HTML and text mode, no matter if referred or unreferred (unless there is a sound technical reason for it, which I'm not aware of).
humm, this is not exactly what I said. Images should be available for download (ie. in the attachemlent list) in text mode. But in HTML mode, they are displayed inline, they don't need to be in the attachement list (as I can right click -> save the image in my browser)
We are in full agreement, as "accessible for download" (I phrased it intentionally this way) doesn't necessarily mean in the case of HTML mails, that they should be shown in the attachment list (they can, but they don't need to), as they are "accessible" anyway - as you correctly described.
Nonetheless, it can still come quite handy to have them in the attachment list, if you want to download all attachments as a single ZIP file (if you have the corresponding plugin installed).
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 21.03.2013 19:11, schrieb A.L.E.C:
There's a question according to http://trac.roundcube.net/ticket/1488783 [1].
There are messages with related images. Normally, they are referenced in HTML bodies (parts), but not always. So, the question is: should we list such attachments on attachments list. We have a few possibilities:
- Do not list any in text and html mode (current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only
(Thunderbird's way).
What's the difference between 2. and 3.? Can you refer images in text mode?
Manfred
- List all in text and html mode (only for completenes, I suppose we
shouldn't ever choose this option).
Implementing this as a user preference will be overcomplicated, we don't want to make it optional, we should choose one. So, what's your opinion?
For now I have no strong opinion, but I'm somewhere between 1. and 2.
Links:
On 03/22/2013 04:24 PM, Manfred Usselmann wrote:
- Do not list any in text and html mode (current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only
(Thunderbird's way).
What's the difference between 2. and 3.? Can you refer images in text mode?
No, you can't of course. The difference is that in 2. we list only images that aren't referred anywhere. We do not list images that are referred by HTML part, no matter if we display the message in text or html mode.
Am 22.03.2013 18:15, schrieb A.L.E.C:
On 03/22/2013 04:24 PM,
Manfred Usselmann wrote:
- Do not list any in text and html mode
(current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only
(Thunderbird's way).
What's the difference between 2. and 3.? Can you
refer images in text mode?
No, you can't of course. The difference
is that in 2. we list only
images that aren't referred anywhere. We do
not list images that are
referred by HTML part, no matter if we
display the message in text or
html mode.
Thanks.
I would prefer 3.
Manfred
An 2013-03-23 08:57, Manfred Usselmann wrote:
Am 22.03.2013 18:15, schrieb A.L.E.C:
On 03/22/2013 04:24 PM, Manfred Usselmann wrote:
- Do not list any in text and html mode (current situation).
- List only unreferred in text and html mode.
- In text mode list all, in HTML mode list unreferred only (Thunderbird's way). What's the difference between 2. and 3.? Can you refer images in text mode?
No, you can't of course. The difference is that in 2. we list only images that aren't referred anywhere. We do not list images that are referred by HTML part, no matter if we display the message in text or html mode.
Thanks.
I would prefer 3.
Manfred
+1
I vote for 3.
If I choose to view only text part, please at least let me see what embedded images should have been displayed. Lot's of html-aware MUA generate text-part with some indication that there were an image here and there, so it is very frustrating if I can't see them at all (I mean without switching to HTML view).
-
A.L.E.C -
Lazlo Westerhof -
Manfred Usselmann -
Michael Heydekamp -
Sébastien BLAISOT