a conversion to plaintext should not contain image urls

VERIFIED DUPLICATE of bug 66035

Status

()

Core
Serializers
VERIFIED DUPLICATE of bug 66035
17 years ago
17 years ago

People

(Reporter: rossi, Assigned: harishd)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 years ago
dup of bug 66035?

Comment 2

17 years ago
I think this is a dup or very, very related.

*** This bug has been marked as a duplicate of 66035 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 3

17 years ago
> this is not plaintext.

Sure it is.

I would have marked it wontfix, but vrfy.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 4

17 years ago
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

17 years ago
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.
(Reporter)

Comment 6

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

Comment 7

17 years ago
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

17 years ago
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.
(Reporter)

Comment 9

17 years ago
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?
(Reporter)

Comment 10

17 years ago
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

17 years ago
> 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

17 years ago
> 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.
You need to log in before you can comment on or make changes to this bug.