why is the <img> alt attribute not always properly displayed

So I have this php script that output an html table with data about some files (like filename, filesize, etc...)

I have this javascript function that displays the picture when you hover a tag belonging to the class "preview". For example, if a filename is: somePic.jpg, when you hover somePic.jpg in the table, the picture will appear next to your mouse.

Now not all these files are pictures, some are .mp3, so of course when you hover them, the javascript cannot display the picture. To deal with this case, I added in the tag (generated by the javascript function), an alt attribute: alt='Preview not available for this type of content.'

And here is my problem, sometimes it works, but sometimes it doesn't! Sometimes you start hovering .mp3 links, and the alt attribute is displayed, then you hover a picture, the picture is displayed, then you hover an .mp3 again, and the alt isn't displayed anymore, but the "broken image" image (the little red cross) is displayed instead...

Sure I could parse the filenames and detect when it's an mp3 and then deal with the case, but I thought the alt attribute was suppose to achieve this... but it's buggy...

Any idea? Does anyone already faced this problem?

Solution

In general alt is for when images are disabled, rather than as a backstop for error conditions. Whilst IMO it's a desirable feature that the alt text be displayed in error conditions, the standard doesn't say it has to:

For user agents that cannot display images, forms, or applets, this attribute specifies alternate text.

and indeed browser behaviour varies. WebKit (Safari, Chrome) will only display a broken image icon and never the alt text; IE tries to render the alt text inside a box with an image icon (which frequently displays poorly).

So you shouldn't rely on alt text being displayed on error.

Sure I could parse the filenames and detect when it's an mp3

Yes, I think you'll have to. Not that that's possible either in the general case since filename/URL extension may well have nothing to do with the actual file type. However if you control all the URLs yourself you may be able to guarantee that all MP3s are called ...mp3.