114287 - a conversion to plaintext should not contain image urls

Status: VERIFIED DUPLICATE of bug 66035

(Core :: DOM: Serializers, defect)

Description

[rossi]

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.

Comment 1

[R.K.Aa.]

dup of bug 66035?

Comment 2

[Håkan Waara]

I think this is a dup or very, very related.

*** This bug has been marked as a duplicate of 66035 ***

Comment 3

[Ben Bucksch (:BenB)]

> this is not plaintext.

Sure it is.

I would have marked it wontfix, but vrfy.

Comment 4

[rossi]

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...

Comment 5

[Ben Bucksch (:BenB)]

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.

Comment 6

[rossi]

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

Comment 7

[Ben Bucksch (:BenB)]

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.

Comment 8

[Ben Bucksch (:BenB)]

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.

Comment 9

[rossi]

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?

Comment 10

[rossi]

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 ]>

Comment 11

[Ben Bucksch (:BenB)]

> 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.

Comment 12

[Ben Bucksch (:BenB)]

> 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.