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

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

verified.

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

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

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.

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?

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

Rewriting summary

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