Taking these to triage.

I can see the broken image link for http://model1.cl/images/andromeda/misc/tag.png 
and when I tried to access it with FF3/IE7/Safari they all gave the same result.  The 
webserver is returning a 404 for those images.

Well, yes when I right click on the tag to open an image it shows me 404 with all 
browsers as well.
But no user will right click on the tag to open it as an image and if you llok with 
IE or Firefox you will ACTUALLY SEE ALL TAGS, with Chrome you just see that "missing 
image" symbol.
I just tried it again and all tags are displaying properly in IE and Firefox but not 
in Chrome. 
I have no idea how to generate a screen shot with Vista, otherwise I would attach it. 

That's not the point!
In IE and Firefox you can see all tags displayed correctly, Chrome shows that missing 
image symbol.

[Confirmed] - Very valid and known Safari issue!

Regarding other browsers:
   Safari 3 - FAIL, Opera 9 - OK, Firefox 3 - OK, IE 7 - OK (and Chrome - FAIL)

Problem only for Safari and Chrome.

This is an already known Safari problem and is exactly because Safari and Chrome are 
not automatically showing the ALT text when the image is missing.  See:
   https://bugs.webkit.org/show_bug.cgi?id=5566

[Upstream] ?

If this is a known issue why Jon just simply closed that issue and marked it as 
Invalid without researching it further? 

Jon, could you please re-open it. 

This is a valid Chrome bug and quiet important. 

Just think about how many million of users are browsing vbulletin forums and 
therefore will prefer not to browse with chrome.

I meant it is a known issue in Safari circles.

Now, hopefully, it will also be known to Jon and the Chrome dev team as well.

Jon, please re-open or re-status the bug as Upstream and label it Reported-to-WebKit 
or whatever label.

This is a valid bug, and the code that needs to be fixed is in WebKit. 

Issue 5846 has been merged into this issue.

Issue 8189 has been merged into this issue.

Issue 16734 has been merged into this issue.

We need someone to take this WebKit bug.  So far no one has claimed it.

Found this page very useful, http://worcestershirewebdesign.co.uk/blog/?p=3
Explaining the real syntax of tags Alt and Title.
I changfed my alt-texts to title tag instead, and works fine with Chrome.

Karen will be handling WebKit issues.  I am moving myself off of being an 
owner of this issue.  She may want to handle these differently so I am 
setting the status as untriaged.

Use title attribute.

The alt attribute is to show an ALTernative text if the image is broken...
The title attribute is to show a short description of the image

So the alt-attribute should be supported and the text should be shown -at the same 
place where normally the image would be- if the image cannot be loaded...

Quote from w3schools:
"The required alt attribute specifies an alternate text for an image, if the image 
cannot be displayed.

The alt attribute provides alternative information for an image if a user for some 
reason cannot view it (because of slow connection, an error in the src attribute, or 
if the user uses a screen reader).

Note: Internet Explorer displays the value of the alt attribute as a tooltip when 
mousing over the img element. This is NOT the correct behavior, according to the HTML 
specification. All other browsers are following the specification, and will only 
display the alt text if the image cannot be displayed.

Tip: If you want to create a tooltip for an image, use the title attribute."

This shows you the difference between alt and title! 
That is why alt should be supported. Please reopen this bug!

Issue 27082 has been merged into this issue.

Please re-open this.

The reason given for closing this case was "Use title attribute."
Using (or not using) the title attribute does not (and should not) affect the display 
of a misdirected <img> element.

To demonstrate, create a file called test.html which contains the following element: 
<img src="C:\DoesNotExist.jpg" alt="alternate" title="title" />
As pointed out in comment 19, the correct behavior in this case would be to display 
the word "alternate" in place of the missing image.
Instead, Chrome displays the "missing image" icon with no text at all.
Note that the width of the box where the image would go is determined by the length 
of the alt text.
This means that the alt text is being used somewhere, but it's just not being 
displayed.

This bothers me very much when viewing IM conversation logs. Please re-open and fix 
this bug. When I need to view conversation logs that have much broken images I had to 
open it in Firefox.

issue 29967

issue 41090

Issue 29967 has been merged into this issue.

Issue 34230 has been merged into this issue.

As mentioned, this is upstream WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=5566

Even though this is an upstream WebKit bug, it doesn't mean it can't be patched in Chromium.  It's been a bug in WebKit for nearly 5 years.  Omniweb has patched it in their code and they are WebKit based.

I think if it's going to be fixed, you're going to have to do it yourself because there's no view in sight of WebKit ever fixing it themselves.  As a browser in the front lines of taking market share, I don't think relying on WebKit to fix the issue is a viable option here.

Also, like FF, the alt text should be displayed with whatever formating text would normally be displayed with in the same location.  So you could use CSS like so:
img {
  color:blue;
  font-size:20px;
}
And the alt text would display as such.

Umm... actually, I just realized that chrome does show the alt text... heh, it seems another issue obscures it.

If you set a width and height on an image that's big enough, the alt text will show.  min-width and min-height are good enough to use.  The problem is, the image alt text will not wrap at all and that little image placeholder icon actually knocks the alt text somewhere else so it doesn't show if it's not much taller than that icon.

It actually does obey any text styling you have listed on the img. so img { font-size:20px; } works, but makes it so the box needs to be even bigger.

Perhaps another bug should be filed as it seems the issue has been a side effect of something slightly different.

Thats insane that this bug is from 5 years ago and WebKit still haven't fixed it. Firefox's and I assume most other browsers way of rendering this is the best approach (treating the contents as an inline element with full style support). Its perfect for situations where you're using images for custom font use, if the image doesn't exist you can make it fall back to something that looks relatively similar. At the moment you get an ugly icon which tells you nothing.

Issue 63738 has been merged into this issue.

Seriously, please fix this now. It has been two years.

As a web designer, I need people to be able to read the "alt" text in case the images break unexpectedly during server maintenance. Otherwise, users will just see blankness and if the image is an important button like "Join Now!" it will be completely USELESS, requiring me to add more text to the page, making it look redundant. 

I'm pretty surprised it's been two years and this hasn't been dealt with yet. A little disappointed.

Agree with last comment, please fix it. It's Chrome's shame.

Webkit needs to fix it.  A link to the webkit bug was already posted here.  They don't seem to see any merit in it at all and haven't even assigned it to anyone.  It's been sitting there since 2005, 6 years.

Doesn't the chromium team ever push bug fixes back up to webkit?  Or can't they push for them to fix certain bugs at all?

I have version 10.0.648.151 and it's still not fixed. I wonder if Acid3 would include this in the test if Google would finally fix this defect.

Come on people! This has been a known bug for six years! What's the point in web standards if browser vendors just ignore them? Why do we spend hours optimising our code for situations like this, only to find it's all a complete waste of time? Such a basic thing, displaying an alt text. It would take a second to fix. Why has it languished broken for six years? This is madness. Somebody, get this sorted, come on!

I agree with aliblack.
I can understand that many bugs aren't easy to fix, but continually failing to display alt text is unreasonable for a company like Google.
Both Google and the Webkit folks have been alternately putting this off and claiming that it's not a problem.
Yes, this is technically a Webkit issue, but you are using Webkit and it's making you look bad. With all the other things that Google can do, this should not be a problem to either fix on your end, or encourage/help Webkit to fix.

There's nothing chromium can do, why are you complaining here?  Have you even bothered reading any of the comments before bothering to post?
Go somewhere it will be useful, like the webkit bug, which has been linked to here, if you read the comments.

@phazei,

Rude.

I've read all the comments and I still don't see the reason why nobody at Google or otherwise is able to claim this bug. All I see is people saying it's Webkit's responsibility, which I find weird considering the seemingly small effort needed to fix this. If I wasn't so swamped right now, I bet even I'd be able to dig into Webkit's code and fix it!

I understand people at Google/Webkit are probably also swamped, but they have all the insight into the code, and it should take a much smaller amount of time for them to fix it.

Even though I can relate to the fact that people can get sick of nagging, telling people to "go somewhere [else]" is _quite_ unhelpful and not very nice. I mean let's be honest, this bug is pathetic. It's been around for 6 years, so it's like... "wtf".

If the bug has been sitting at Webkit since 2005, I think it's fairly okay to assume they're not interested in fixing it, which makes people want to try somewhere more trusty; and they make that place out to be Google. :P

If you look at the comments on the webkit bug, notice that I'm "Adam" and have been 'nagging' them.

I mentioned in comment 28 that omniweb fixed it in their webkit based browser, and in comment 30 the actual nature of the bug.

If you want it fixed, nag the right people.  chromium seems set on keeping it as an external dependency issue.  So go sign up for bugs.webkit and get it attention.

Chromium seems set on keeping it as an external dependency and Webkit seems set on keeping it unresolved. :|

Actually this issue does not occur. If you try to set an unexisting images sizes larger the text will show. The alt text isn't displayed because the broken image has some kind of borders and hides the text. Try to enforce a larger image by specifing it's size and the text will become visible.

That's not the issue now, the issue is that the broken image shouldn't even be there.

Having to force the box size shouldn't be necessary. The current behavior is very much an issue!

Well, the broken image should be shown if there is no alt text.

If there is alt text, that should be shown instead, perhaps being preceded with an inline broken image so one can still be aware that an image was supposed to be there.
The alt text should be stylable as well.

Instead of complaining you could also create a patch yourselves. Your whining doesn't help anyone. All you managed to do is bringing the number of stars back to 51.

@karen, please lock this issue with restrict-addissuecomment-commit

Complaining? We're trying to drive this bug towards fixing! Pardon us if we're not experts on where that should be conducted if not on the bug report itself. :D (:P)

Regarding the broken image:

"Except where otherwise specified, the alt attribute must be specified and its value must not be empty [...]"

-- http://www.w3.org/TR/html5/embedded-content-1.html#general-guidelines

"The image given by the src attribute is the embedded content, and the value of the alt attribute is the img element's fallback content."

-- http://www.w3.org/TR/html5/embedded-content-1.html#attr-img-alt

"Some embedded content elements can have fallback content: content that is to be used when the external resource cannot be used (e.g. because it is of an unsupported format). The element definitions state what the fallback is, if any."

-- http://www.w3.org/TR/html5/content-models.html#fallback-content

I'm not so sure the 'broken-image' image should even be there at all. Seems more like it's a relic from old behavior if anything.

Chromium developers be advised; I have a blog post scheduled for tomorrow afternoon, to mock you (but mostly WebKit) for not having patched this like OmniGroup did 3 years ago. It's just the kind of absurd pedantry that we don't have time for anymore. Lets get this done.

Aiaiaiai....I read the comments....i have nothing else to say then, shame on you chronium/google, very dissapointing.

When will it be fixed?

Needs to be fixed.  I don't care who does it.

Agree it needs to be fixed, a simple bug that even Netscape 10+ years ago supported nicely.

It's not just for when the image isn't supported... for branding purposes on a job site search engine for instance the alt tag would show the text of the companies name automatically for instance if a branding image hasn't been put in the image repository yet. 

"Well, the broken image should be shown if there is no alt text.

If there is alt text, that should be shown instead, perhaps being preceded with an inline broken image so one can still be aware that an image was supposed to be there.
The alt text should be stylable as well."

 I actually like firefoxs' solution that only shows the alt text, prettier and more elegant. having outside customers see the broken image link is ugly and not customer friendly. 

Issue 114145 has been merged into this issue.

Please make sure ALT codes show up.

Case in point:
My http://www.couchsurfing.org/people/jidanni/ makes extensive use of
images from sites prohibited in China.

I was forced to shorten the ALT codes to make sure they fit within
Chromium's boxes.

Else Chinese readers will think it is me who wrote such an irresponsible
web page with no ALT codes.

Thankfully at least Chromium still shows the rectangle, vs. certain
other browsers https://bugzilla.mozilla.org/show_bug.cgi?id=41924#c216 .

+1, for all the good it'll do. This bug really makes Chrome look bad (even if it's Webkit's fault). Firefox does it correctly and seamlessly. 

Seems like this is a layout issue in WebKit: alt text does not have any overflow properties beyond "hiding" the alt text if there is any overflow. Even clipping would work better. This issue occurs when an image width has been manually set and the text does not fit into the line box. Mozilla has a moz-broken selector which could be used with replaced and generated content. That may be how we eventually get this addressed in WebKit-- by adopting additional CSS conventions.

Issue 132256 has been merged into this issue.

<p>Image Alt Test<br>
<img src="missing.jpg" alt="Image is not found.. Showing Alt Text">
</p>

Alt Text is not painted. It just shows broken image. Please help to fix it..

Screenshot attached.

	Screenshot.png 96.0 KB View Download

The bug also trigger when the img refers an existing image file that Chrome does not handle, like for instance old XBM files.

Please fix it. It was since 4 years. Hello Google, please! :)

STOP! This issue is not a bug. Please note that if the broken image is expanded or is big enough the ALT text is displayed. So please close this issue. 

No, to show ALT text in Chrome, the space must be more than enough, that's a bug.

More than 4 years to display image alt tags?
Unbelievable...

Wow, will you let it complete 10 years?
I've reported it as #244357 because I haven't find this in my search before.

Just to be clear, this issue is related to a confirmed bug in WEBKIT, which can be tracked here:

http://wkb.ug/5566

Feel free to add input and follow progress on the fix at that link, as this will likely not be addressed directly here or by the chromium team at all (unless it's done in Blink).

Blink is a fork of WebKit, this puts the responsibility completely in Chromium project now ("borrowing" the code from WebKit project as long as it fits or not, regardless, Chromium isn't tied to WebKit anymore).

Issue 244357 has been merged into this issue.

You have a point, Rafael, which is why I mentioned Blink. On April 5 this issue was labeled for Blink, but the status wasn't changed from "ExternalDependency" (and there still isn't an owner). Still, I have hope that this is the year the bug will be fixed..

Thanks for updating the issue, though (getting off-topic, sorry) it looks like quite a few other issues have the same probably-stale "ExternalDependancy" status since the bulk move of issues from WebKit to Blink:

https://code.google.com/p/chromium/issues/list?can=2&q=label%3ACr-Blink%20label%3Abulkmove%20status%3AExternalDependency

Sep 3, 2008 this was reported. I want to second comment #30 as a work-around, and a hint at the underlying issue. Alt text is pretty important, and it's shameful that 6 years later this still isn't addressed.

Any update for this issue

Looks like someone took the advice of comment #30 and filed a new issue that properly describes the bug--see Issue 157207.

Everyone, feel free to star it so it can get more attention.

Fix in review.
https://codereview.chromium.org/328703003/

lol, devs cant fix this bug for 6years, srsly? #fail

Should be fixed by https://chromium.googlesource.com/chromium/blink/+/94a5b88aded99c887831975c6dc6be7104039369

Please try it out in a Canary build (https://www.google.com/chrome/browser/canary.html) and let me know.

Issue 440733 has been merged into this issue.

Works for me. Thanks

Issue 157207 has been merged into this issue.

I can also verify it works in Version 42.0.2310.0.

Issue 247273 has been merged into this issue.