the plaintext serializer converts an image to plaintext by taking the "alt" attribute, or nothing if alt="" or title if there is one and no alt and if there's no alt and no title it takes a string consisting of <http://absolute.ima.ge/url> . this is not plaintext. it should be nothing if there is no alt and no title.

dup of bug 66035?

I think this is a dup or very, very related. *** This bug has been marked as a duplicate of 66035 ***

> this is not plaintext. Sure it is. I would have marked it wontfix, but vrfy.

i meant this one more general... because #66035 is only for clipboard, but there is more plaintext conversion going on, for plaintext emails, window.getSelection() etc. and i mage a patch for 66035 which changes plaintext conversion in general and ppl said that's not ok, so i wanted to start a discussion about general plaintext conversion, because i think it's valid for getSelection etc. too, not to use image urls...

I gave my reasons in the other bug, why I think that adding the URL is essential and your patch causes dataloss. (If the Composer UI adds alt="" without being asked, this is a bug IMO in Composer, IMO. Please file it, if so.) YouÄd have to argue, why I am wrong.

that's an easy argument: adding an image without alt attribute would not be standards compliant. why should composer do that?

alt="" means that text-only UAs should not render it, i.e. it is irrelevant to the content and just visual fluff. If the user manually inserted an image, that is almost never true. Thus adding alt="" automatically causes dataloss. alt="" does *not* mean "I don't know what to put there". I think, we should provide an extra checkbox like "This image is not important for the content", which disables the alt textfield in the dialog and inserts alt="" in the doc. Anyways, being syntactically wrong is IMO better than being semantically wrong.

And: How do you want plaintext readers to get to the image after reading the plaintext mail, if you don't tell them the URL? (No matter what |alt| is sat to.) If there is an image in a mail (the most common usage for our HTML composer), you can bet that it's important.

if the image is inline in the email, the url isn't interesting, because the image is a part of the email body, and most text-email-clients will have an option to view them extarnally or save them. and if users really want to give a hint what the image was, they can do this with the alt tag (which at the same time takes away every reference to the image url, because then the alt is sent). if there is an external image, why not set the default alt attribute to the url instead of "", be standards compliant and let us all be happy?

and i don't understand the difference between plaintext conversion and plaintext conversion. why is it ok for you to remove the url in 66035 but not in general? you could use the same arguments there: if you copy some text, paste it into a text file, you will never have any reference to the image again either (if 66035 will be fixed some time). also you would have to file a bug that image urls should always be added in composer, even if there is an alt attribute. we could do something like <http://www.img.com/img/img.png [ nice image ]>

> and i don't understand the difference between plaintext conversion and plaintext > conversion. why is it ok for you to remove the url in 66035 but not in general? If you ask me, I'd use the URL in both cases (in fact I did as you can see from the code). But copy&paste is a manual operation, and the user is very much aware that copy&paste from a formatted text (like HTML) to plaintext will lose some data - sometimes, he even expects that. The conversion happening during mail sending however is automatic and should be as transparent as possible. The sender won't see which data got carried over until it's too late (if he cares at all) and the recipient might never see the original data. In this case, dataloss is not acceptable. The plaintext converter was written with that goal in mind.

> if the image is inline in the email, the url isn't interesting, because the > image is a part of the email body, and most text-email-clients will have an > option to view them hm, right. But the *place* of the image is still important, sometimes (not often, given). > and if users really want to give a > hint what the image was, they can do this with the alt tag The problem is that they don't understand the consequences. > if there is an external image, why not set the default alt attribute to > the url instead of "", be standards compliant and let us all be happy? Because the WAI says that no placeholder should be added to alt. This would be a bad solution for audio browsers etc.. Why not just let the converter output the URL from the href? Then we don't have crappy alt text in the doc. As a bonus, we don't have to do anything - that's what the current code does. :-> BTW: I filed bug 114531 about the Composer image dialog.