180991 - Conversion to plaintext of image tags poor! ('alt' is inlined without comment)

Status: NEW

(Core :: DOM: Serializers, defect, P5)

Description

[Jean-Francois Ducarroz]

When an image tag is converterd to plain text, it's just replaced by it's
alternative text. There is no way for the user to guess an image is suppose to
be there. Worst, if the image does not have an alternative text, nothing
appears! Netscape 4.x does a much better job:

case 1) Hello <image src="url" alt="World">
Mozilla: HelloWorld
4.x:     Hello [World]

case 2) Hello <image src="url">
Mozilla: Hello
4.x:     Hello [image]

That will really help mail users when sending a converted HTML message

Comment 1

[Tanu Mutreja]

This has been a subject of long discussions in bug# 66035. Based on that I'm 
marking it as INVALID.

Comment 2

[sujay]

verified.

Comment 3

[Mike Cowperthwaite]

Reopening.
The "long discussion in 66035" was about the representation in plain text of an 
image that has no 'alt' -- that is, whether to display the 'src' for an image if 
no 'alt' was provided.  That has been done.

There was no discussion there of the best display of an image that *does* have 
an 'alt'.  The examples in the original report show what I would have expected 
before reading 66035; however, the example in the original report of that bug 
(almost) is a case for simply shoving the 'alt' text inline.

In that case, dictionary.com is using an image (prime.gif) for the accent mark 
in a word's syllabic breakdown.  The image does not have an alt tag, but it 
could -- for instance, it could use the apostrophe.  In that case, the pasted 
text would be better as:
   def'i·nite·ly adv.     rather than      def[']i·nite·ly adv.

Note that 'alt' is currently not being included at all in serialization, which 
is a problem in itself (bug 212177, or whatever it might be a dupe of).

Comment 4

[Bob Firth]

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

Comment 5

[Mike Cowperthwaite]

Reopening.  Bob Firth, this is a DOM-to-Text issue, not a layout issue.

That purported duplicate does have a lot of information in it (and a lot of 
noise).  It helpfully points to bug 180622, which shows that the intended design 
for Mozilla is to always show an icon along with the alt text in layout.  That 
implies to me that some sort of indicator for the alt text in plaintext 
conversion is also desirable, such as that described in the original report.

Comment 6

[Hixie (not reading bugmail)]

The icons next to the alt text are needed so that you can access the context
menu. But in a serialisation, the fact that it was an image is irrelevant, IMHO.

Unless mail has special needs for some reason?

Comment 7

[Hixie (not reading bugmail)]

(Maybe we should insert U+FFFC where we would have inserted the icon?)

Comment 8

[Robin Lionheart]

Rewriting summary

Comment 9

[Mike Cowperthwaite]

(In reply to comment #8)
> Rewriting summary

Incorrectly.  See comment 5: this bug is about TEXT, not LAYOUT.  Borders and icons are not relevant.

(In reply to comment #6)
> But in a serialisation, the fact that it was an image is irrelevant, IMHO.

I agree, but depending on how the <img> is placed inline, there can be problems with readability in the serialization.  Most 'alt' text doesn't have leading or trailing space or punctuation, so if the <img> falls inline in the text, its 'alt' is concatenated without separation.  How much of a real-world issue this is, I don't know -- in the case of the smiley, the alt text *has* spaces, in Mozilla.  And as in comment 3, some cases of delineation would be distracting.


> Unless mail has special needs for some reason?

Mail users may see this more often, particularly when replying to an HTML message in plain-text.

Comment 10

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.