The alt text of an IMG element is alternative text, that is, text that should completely replace the image, if the image cannot be shown. In other words, if the image could not be drawn, then it should not be replaced by a box containing the alt text, instead, the alt text should be drawn inline. The quoted uri has more on this, including some tests. Lynx does this correctly. (Note: I really don't know which Component this applies to. Layout? Content Model? Rendering? Viewer App?)

Why not fix this in version 5? This is actually an important issue, even if it does require some thought before implementation. Come on! Be the first graphical browser to do this right!!! (BTW, the page moved. Uri was corrected.)

I agree with you that the behavior you describe is the correct bahavior. The two reasons why this probably won't get done for 5.0 are: - time. It takes time to redo the way this works - backwards compatibility. Even though you're right and we're doing it wrong, we've always done it wrong. To change it will "break" a number of pages out there We are planning on properly implementing this for the OBJECT tag, which means you could use the OBJECT instead of the IMG tag and get what you want. I'll mark it REMIND instead of LATER, and see if we can do it if we have time.

That sounds fair to me. :-) RE the backwards compatability issue: couldn't this be one of those DOCTYPE-based decisions? (e.g., CSS inheritence-into-tables is, IIRC, switched to "compatability" mode depending on the DOCTYPE of the document.)

Setting all current Open/Normal to M4.

In the case of an inline image, it makes sense that the alternate text would be displayed inline, of course. However, if using CSS the image is specified to be block-level, floated, or absolutely positioned, then I don't think it makes sense for the alternate text to be displayed inline. In that case it makes the most sense to display the alternate text as block-level, floated, or absolutely positioned. This is one of those areas where the HTML4 spec isn't of much help, because it only discusses inloine-level images. Cc'ing David Baron for his insight as well

Okay, this is now enabled on all platforms (tested on Windows and Unix). We'll now display the alternate content (no border or broken icon) if the image can not be rendered. We display the alternate content in the same fashion as the image was displayed. That means if the image was floated or positioned, then the alternate content is floated or positioned. That seems the most sensinble, at least until CSS provides a way to specify different style info for the image when it's replaced versus regular

I agree about the positioning. Treat ALT of an IMG as if it were the content of an OBJECT, and if the image exists, then the ALT is replaced by the image (and the IMG element is a replaced element). I think that's what you're now doing.

Yes, that's what I'm doing. Thanks for the clarification

Yup, I agree with the above. I haven't tested it yet, but expect to do so in the next few days.

*** Bug 6166 has been marked as a duplicate of this bug. ***

This bug is one of many related to alternate text of images. All these bugs have been marked. To find related bugs, search the description field for the string "[ALT]".

*** Bug 3268 has been marked as a duplicate of this bug. ***

This has regressed.

I just turned this feature back on.

I'm reopening this bug because we still have a plethora of problems with alt texts on broken images. There is a comprehensive test page for this here: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html We currently fail more than 50% of the test lines. To be precise, the problems are: * Images with alt="" are not using the empty alt text. * Broken <input type=image> elements still get placeholders. * The <input type=image> element's "name" attribute is ignored. * Images that are links are unclickable. * Images that are still downloading but have no explicit width=/height= are being given placeholders (which is pointless). * The :first-letter pseudo-element is not applied to alt text.

Ian, I'm really starting to regret I let you talk me into implementing this feature.

Ian, please open a new bug for the problem of <input type=image>, I'll give that bug to Eric.

The <input type=image> issue is now covered by bug 8979.

Thanks

To address the remaining concerns one by one: * Images with alt="" are not using the empty alt text. THIS WILL BE FIXED AT SOME POINT. TODAY I CAN'T TELL WHETHER THE ATTRIBUTE IS EMPTY TEXT OR NOT SPECIFIED AT ALL * Images that are links are unclickable. THIS IS BUG #5349 (I'M ADDING IT TO THE DEPENDS LIST ABOVE) * Images that are still downloading but have no explicit width=/height= are being given placeholders (which is pointless). THAT WAS A RECENT CHANGE TO FORCE A MINIMUM SIZE FOR THE FRAME FOR LOADING IMAGES. I DON'T REALLY LIKE THIS, BUT IT'S MORE BACKWARDS COMPATIBLE, AND IT DOES OFFER THE ADVANTAGE OF PROVIDING THE USER FEEDBACK THAT WE'RE STILL LOADING IMAGES. THE DOWNSIDE IS THAT IT TAKES UP EXTRA SPACE AND MAY ALTER THE DOCUMENT APPEARANCE. * The :first-letter pseudo-element is not applied to alt text. THAT'S FOR KIPP TO FIX AT SOME POINT.

The problem I mentioned about now being able to tell whether the attribute value is an empty string vs. not specified at all is when using the DOM image interface. The bug number is 6052, which I'm adding to the depends list above

Regarding images that are still downloading but have no explicit width=/height= being given placeholders, note that the current system means that the page will almost certainly have to be reflowed, and in the meantime, the page can be difficult to read (frames all over the place). If instead we assume that images without dimensions will fail until proven otherwise, then if the image is broken, a reflow will not be needed, and if the image is ok, then the reader will be pleased that the page has suddenly improved. Also, feedback is already being given by our "remaining items to download" status line and the throbber. The page itself doesn't really need to worry about that, IMHO. Not that it matters much to me - I don't think the pre-download behaviour is specified by the specs. [About the alt="" vs no alt problem: you may wish to investigate how the CSS code figures out an attribute is present or not, since that seems to work ok. It probably uses a totally different interface, but it may be worth a look...]

As agreed with Beth, assigning myself as QA contact for all 'alt text' bugs...

*** Bug 16619 has been marked as a duplicate of this bug. ***

The M10 build replaces a broken image without ALT text, with the filename (minus the extension) of the image. I think that's going a bit too far. Don't you? I mean this whole inline alt text will mess up a lot of pages, but I guess it's tolerable since it's 'spec.' But then it's a bit much, IMHO, to go ahead and start putting file names as inline alt text.

That's what the spec says. The filename is only used as a last resort

Yup - if you want the image to not display any alternate text, e.g. for decorative images, then you should set alt="". This is currently broken but that is blocked on bug 6052, which is blocked on bug 1663. BTW -- not giving the alt text is invalid in HTML4. If pages don't give the alt text then they will already be "breaking" many pages in browsers that already do the right thing, e.g. Lynx and voice browsers.

You're right there with that point. But I'm also concerned about the layout aspect of things. What about the width and height of broken images? If you know the width and/or height, can you at least make that much space on the page (without the image frame)? Or in the case of a image that's part of the link, the bounding box would be that size (if the border attribute is more than 0, or missing). Not using this data could break a lot of pages (of course these pages would already be broken, because of missing images :( ,but nevertheless). I also couldn't get apprunner to leave the images out. When they are left out the above point make more sense. In other words not using the width and height when leaving images out (either by necessity in the case of broken links, or by the users choice) would junk out the layout of a page. Of course you're not supposed to use use images for layout according to the spec, but that's been done so much already on the web, and these pages (with images turned off) would look terrible.

If the images are { display: block } then their dimensions are used. Anyway, that the "layout aspect of things" is also already messing up Lynx and voice browsers in the cases where the pages are badly designed. This is just another case where this feature will actually force authors to write more accessible pages.

*** Bug 18491 has been marked as a duplicate of this bug. ***

Much to everyone's surprise I'm working on fixing this. Vidir finally admitted he's not going to fix the DOM APIs, and so I'm directly getting the attribute values using the nsIContent::GetAttribute() function One question. What if the user does this: 'IMG alt title="title" src=...', i.e., there is an ALT attribute specified but it has no value. Is that the same as alt="" or should we use the value of the TITLE attribute instead?

Woohoo! :-) <IMG alt title="title" src=...> It's invalid. I'd say treat it as alt="", since 'alt' is specified but has no value, which is pretty much what alt="" means.

Good. That's what I am doing. As soon as the tree opens again I'll check the changes in

For the <object> element equivalent of this bug, see bug 797, bug 15019, bug 22047, and bug 678.

s/bug 22047/bug 22037/ Ah, the miracle of cut and paste. A great proponent of the main feature of computers: allowing users to make more mistakes, quicker than ever before. :-/

I changed it so that we now look for the attribute value being the "" (empty string) and in that case we set the alternate content to "" instead of trying the next attribute That's what was left to fix in this bug report. If you see that image buttons (or something else isn't working), then create a new bug please

Marking verified. Woohoo! Remaining bugs are covered by: bug 8979 - <input type="image"> issues bug 15545 - Broken floating IMG elements dissapear bug 23691 - Inline IMGs without a size should not have a placeholder box

Reopening. IMG alt does no longer go inline using 2000042215 nightly on Windows 2000.

How come this is still M15? M15 is already out!

Changing milestone since M15 is out.

mLowSrcImageLoader seems to be always created even if lowsrc attribute is not there.

Reassigning to rods since he added the lowsrc stuff. See bug 27388.

Thanks for the patch, but I needed add a couple of other additional checks. It's fixed.

Verified fixed using 2000050215 nightly build on Windows 2000.

bug 1994 has now become bug 75185. Removing dependencies from this bug to clear the confusion.