Bug 5566 - ALT attribute value sometimes not displayed when image is missing
: ALT attribute value sometimes not displayed when image is missing
Status: NEW
: WebKit
Images
: 420+
: All All
: P2 Normal
Assigned To:
:
: InRadar, Qt, QtTriaged, ReviewedForRadar
:
: 11200 47211 55056
  Show dependency treegraph
 
Reported: 2005-10-30 13:53 PST by
Modified: 2013-04-27 19:45 PST (History)


Attachments
Test Case (7.90 KB, application/octet-stream)
2005-10-30 13:58 PST, Andre-John Mas
no flags Details
HTML Only test case for identifying behaviour (317 bytes, text/html)
2009-12-08 06:13 PST, Andre-John Mas
no flags Details
Test Case with width and height on image (479 bytes, text/html)
2010-11-16 00:42 PST, Adam
no flags Details
Siimple HTML test cases with alt text with and without size info (595 bytes, application/octet-stream)
2011-06-03 13:54 PST, Joe Wild
no flags Details
Example patch of corrected alt text sizing (6.92 KB, patch)
2011-06-06 11:28 PST, Joe Wild
no flags Review Patch | Details | Formatted Diff | Diff
Fix the image rendering sizing so that broken image icon and alt text will be displayed when they are avaiable (448.83 KB, patch)
2011-06-20 12:35 PST, Joe Wild
webkit.review.bot: commit‑queue-
Review Patch | Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-01 (1.66 MB, application/zip)
2011-06-20 12:55 PST, WebKit Review Bot
no flags Details
Fix the image rendering sizing so that broken image icon and alt text will displayed (515.89 KB, patch)
2011-06-24 10:55 PST, Joe Wild
benjamin: review-
benjamin: commit‑queue-
Review Patch | Details | Formatted Diff | Diff
Basically, we can display the alt text value if there is the efficient space. (1.54 KB, patch)
2013-04-01 19:32 PST, kyounga
kyounga.ra: review?
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-10-30 13:53:59 PST
If I have an IMG tag with a none empty ALT attribute, then the text is not
displayed if the image is missing. Instead I just see the missing image question
mark.

As an example:
  
<img src="./missing_image.gif" alt="My web site image"/>

"./missing_image.gif" does not exist, so the value defined in the "alt"
attribute should be displayed. This works in Firefox and Opera, but not in Safari.
------- Comment #1 From 2005-10-30 13:58:28 PST -------
Created an attachment (id=4538) [details]
Test Case

Attached is a test case. I have just tested this with Omniweb in addition to
the browsers that I tested with originally and noticed that the ALT text does
get displayed. This may be limited to Safari's use of the API.
------- Comment #2 From 2005-11-04 15:27:12 PST -------
<rdar://problem/3384556> Should display ALT attribute of IMG tags in missing-image case also
------- Comment #3 From 2006-07-08 01:51:14 PST -------
I think OmniGroup just fixed the bug at their end. It's not a safari issue, other WebKit users (RSS readers for example) also have this problem.
------- Comment #4 From 2006-07-13 16:29:06 PST -------
From looking at frameworks included with OmniWeb.app, I can confirm that they aren't using the version of the framework bundled with the system.
------- Comment #5 From 2006-12-17 14:34:02 PST -------
*** Bug 5753 has been marked as a duplicate of this bug. ***
------- Comment #6 From 2006-12-17 14:34:55 PST -------
Note that alt text will show if the error image leaves room for it, for example:
<img src="#" alt="This text should show" height="60">

It would be nice to have a decision on how to render missing images with alt text
(a) when their dimensions are specified
(b) when their dimensions are not specified
In the former case, when the text and the error image won't fit together, what do you do? In the latter case, how do you determine what size to use for the image?
------- Comment #7 From 2006-12-17 17:52:17 PST -------
(In reply to comment #6)

I think in the latter case, the size of the image should be 300px x 150px as specified by the CSS spec. See:

http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width
http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height
------- Comment #8 From 2006-12-18 11:35:21 PST -------
I wrote this spec for the Mozilla guys years ago:
   http://hixie.ch/specs/alttext
I encourage you to use that as the answer to the above questions.
:-)
------- Comment #9 From 2007-12-02 18:17:15 PST -------
*** Bug 16253 has been marked as a duplicate of this bug. ***
------- Comment #10 From 2008-05-20 14:03:40 PST -------
This is a failure to comply with User Agent Accessibility Guidelines 1.0, section 2.9 (Render conditional content automatically):
http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#tech-configure-conditional-content

I believe Safari+WebKit-based browsers should be following Ian "Hixie" Hickson documentation and recommendation.

2 testcases in that sense:
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/FormattedAlternateText.html

http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/ExpandingAltTextForImages.html

Voting for this bug!

Gérard
------- Comment #11 From 2008-06-13 11:37:25 PST -------
*** Bug 17967 has been marked as a duplicate of this bug. ***
------- Comment #12 From 2008-06-25 21:41:59 PST -------
WAI and UAAG 1.0 testcase:
http://www.w3.org/WAI/UA/TS/html401/cp0203/0203-IMG.html
------- Comment #13 From 2008-12-08 16:41:58 PST -------
The Chromium Bug is: 
http://code.google.com/p/chromium/issues/detail?id=773
------- Comment #14 From 2009-07-08 16:33:26 PST -------
http://code.google.com/p/chromium/issues/detail?id=773
------- Comment #15 From 2009-07-08 17:08:15 PST -------
What is the status of this ticket? 

If OmniGroup did indeed fix the bug at their end, have they provided any source code of the fix they made?
------- Comment #16 From 2009-07-08 17:59:41 PST -------
I contacted Omni Group and they have pointed me to the source of their modified version of Webkit:

http://www.omnigroup.com/ftp/pub/software/Source/MacOSX/Frameworks/

Hopefully this should prove useful to the developer fixing this ticket.
------- Comment #17 From 2009-10-05 07:40:48 PST -------
Per Maciej/Rik's request, I'm commenting on this bug for a problem that should be directly related.

I just had a bug reported on me that the "Print" text in my application wasn't showing up in Safari/Chrome (sorry, internal app, so I can't link directly).  Instead all the user saw was a blank gray box.

The reason for this is that I was waiting on an actual print icon, and so for now had just slotted in <img alt=Print> in anticipation of receiving the actual image soon.  I was unwittingly relying on the Firefox rendering, where doing this is visually indistinguishable from simply putting the text "Print" at the same location.

The IE behavior is also satisfactory (placing a broken image icon before the text "Print"), if somewhat less desirable than Firefox's behavior.

Webkit, however, appears to render a blank opaque image over the alt-text, completely obscuring it when the text/image is very small like in my example.

I was forced to work around this by replacing the <img> with a <span> for now, and will later have to switch it back to an <img>.  However, I know of at least one other place where I have relied on Firefox's rendering of a small broken image that can't be so easily replaced when the image is unavailable.  Apparently that place is simply inaccessible to my Safari and Chrome users when the image is unavailable.

I suggest adopting either Firefox's or IE's behavior in this situation, with a preference toward Firefox's behavior.
------- Comment #18 From 2009-12-08 01:33:15 PST -------
I'm unassigning Adele to get more feedback.

Feel free to reassign if it's inappropriate.
------- Comment #19 From 2009-12-08 02:08:35 PST -------
My preferred behaviour would be to treat it like an anonymous text node, i.e. not stylable, and indistinguishable from replacing the whole element with its @alt text. This probably goes against other people's opinions, but it's mine.
------- Comment #20 From 2009-12-08 05:59:08 PST -------
I suspect the way to render the text when dimension are not specified would be to either display to fit the text, if room is available, or truncate the text and fit in ajoining area if room is not available.

We would have to see what the other browsers do and what the specification suggests. At least, if the other browsers are consistent amongst themselves, then we should aim to follow their lead.
------- Comment #21 From 2009-12-08 06:13:01 PST -------
Created an attachment (id=44469) [details]
HTML Only test case for identifying behaviour

I have attached a simple test case that can be used for comparing the behaviour of different browser when it comes to the image alt.

So far I have tested this with:

- Firefox 3.5, MacOS X: case 1 the text is shown on one line; case 2 the text is wrapped.
- Opera 10.10, MacOS X: case 1 the text is shown on one line, with a box around it; case 2 display as case 1

If anyone has improvements to make to the test case, then feel free to add to it. I haven't made time to look at the specifications at this point.

My personal preference is the way Firefox is handling things, since I feel it makes the best compromise, but I am just one voice.
------- Comment #22 From 2010-03-17 19:32:52 PST -------
Is there any updates on this or any plans to fix this?
------- Comment #23 From 2010-07-01 21:22:38 PST -------
I would love to see some progress on this one.

As pointed out by some others, there are quite a few people reporting this problem on the following Google Chrome bug thread: http://code.google.com/p/chromium/issues/detail?id=773
------- Comment #24 From 2010-07-02 15:41:44 PST -------
(In reply to comment #6)

> a decision on how to render missing images with alt text
> (a) when their dimensions are specified (...) and when the text and the error image won't fit together, what do you do?

This has been answered in UAAG 1 and UAAG 2. 

"
allow the user to configure how the conditional content should be rendered. For example, within the [author-]specified [placeholder] geometry, or by ignoring the specified geometry altogether.
"
Techniques for User Agent Accessibility Guidelines 1.0
2.3  Render conditional content
Example techniques, item 4
http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#gl-feature-on-off

So, within the [author-]specified [placeholder] geometry would mean truncate (if exceeding) while ignoring [author-]specified [placeholder] geometry would imply to expand as needed, necessary by text replacement.

"
In cases where the alternative content has different dimensions than the original content, the user has the option to specify how the layout/reflow of the document should be handled. (Level A). 
"
User Agent Accessibility Guidelines 2.0 (*DRAFT*)
W3C Working Draft 17 June 2010
Guideline 3.1 Provide access to alternative content.
http://www.w3.org/TR/UAAG20/#principle-perceivable

In other words, the user chooses again via user prefs/settings: truncate if exceeding author-specified placeholder dimensions or expand if needed to render all alt text.


Firefox 2+ renders alt text inline without truncation of alt text when in standards compliant rendering mode and this can be verified with the 2 testcases I provided. Firefox follows Ian "Hixie" Hickson recommendation here (which I propose and recommend too). The 

(in about:config)
browser.display.force_inline_alttext      

http://kb.mozillazine.org/About:config_entries#Browser.

explains what happens in backward-compliant "quirks" rendering mode when  
no alt text is provided and when author-specified placeholder dimensions are provided.

(In reply to comment #19)
> to treat it like an anonymous text node, i.e. not stylable
Anonymous (text, block box) node inherit inheritable properties (like color, font-size) from their container.

> and indistinguishable from replacing the whole element with its @alt text.
Replaced content should be styled according to inherited properties from containers, otherwise it can/will become very distinguishable from their container.

<h1>Welcome to <img src="brand-logo.gif" alt="Brand Name"></h1>

Let's say brand-logo.gif is unretrievable here.
Why the replaced textual content "Brand Name" should not be using a default font-size 2em? Why should it be using a 16px font-size? 
Firefox 2+, Opera, Safari 3.1+, Konqueror 4+, IE8, Amaya all have an user-agent default stylesheet setting for <h1> heading set to a font-size of 2em (32px). Unstyled body text is set to 16px by all browsers (user-agent default stylesheet).
Recent releases of all mainstream browsers are following appendix D of CSS 2.1.

regards, Gérard
------- Comment #25 From 2010-07-28 17:57:21 PST -------
Seriously? 5 years? wow.
------- Comment #26 From 2010-07-28 18:04:10 PST -------
5 years is a long time. 

What I would suggest is implementing something, possibly which ever one is the easiest and then tweak it later on. This way at least the ticket can be marked as fixed and then any refinement can go in another ticket.

As mentioned before Omni already provides a solution in their version of Webkit, so why not just use that code for the mean time?
------- Comment #27 From 2010-08-19 17:07:25 PST -------
Actually, I noticed something very interesting, at least on 528+ (6.0.472.36 beta)

Here's my post from: http://code.google.com/p/chromium/issues/detail?id=773#c30

If you set a large enough width and height on an image, the alt text will show.  min-width and min-height will work.  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.


It should act like a div with overflow hidden and maybe that icon floated right.  The text should wrap around within the constraints of the image.  But that's only for images with set dimensions.

For images without set dimensions, the method FF handles it is nice, just replace the image with the alt text like it were on the page, completely selectable and <strike>searchable</strike>

But it would be nice if it were searchable.
------- Comment #28 From 2010-11-15 15:55:49 PST -------
*** Bug 34919 has been marked as a duplicate of this bug. ***
------- Comment #29 From 2010-11-15 16:02:46 PST -------
> This is a failure to comply with User Agent Accessibility Guidelines 1.0, section 2.9 (Render conditional content automatically):

Reading comments in this bug, I struggle to understand what its relation to accessibility is. How does whatever WebKit displays for missing images affect users who need accessibility?

This seems to be a pure compatibility issue to me, and in cases where I see missing images on the Web, I would always prefer ALT text to not be displayed, in fact.
------- Comment #30 From 2010-11-15 20:56:44 PST -------
Blind people maybe?  Text only browsers?  Screen readers?  Placeholders?  Turning images off for low bandwidth browsing?
If someone doesn't want anything displayed for alt, they can leave alt empty.  If I put something in alt, I expect it to be displayed if the image isn't there.  That's how it's supposed to work.  It's not an extra feature or anything.

And aside from all that, if you look at my previous comment, it does work.  It works if the image dimensions are wide enough.  So the current functionality is inconsistent.  The missing image icon shouldn't interfere.
------- Comment #31 From 2010-11-16 00:18:32 PST -------
> Blind people maybe?  Text only browsers?  Screen readers?  Placeholders?  Turning images off for low bandwidth browsing?

These are not the topic of this bug. This bug is about displaying ALT text for missing images only - resources that the browser tried to fetch, and got HTTP code 404 Not Found. This is solely for the (questionable) benefit of sighted users, and only in cases when the site is broken anyway, having bad links to its images.

This is how the bug was filed originally, and I don't think that it should be repurposed to track other issues with ALT that we might have. That would be quite confusing, and can only slow down moving such issues to resolution. But if there are other issues indeed, it would be really appreciated if you could file them as separate bugs.
------- Comment #32 From 2010-11-16 00:42:01 PST -------
Created an attachment (id=73972) [details]
Test Case with width and height on image

The issue is the alt text isn't displayed properly because the image icon is in the way.
------- Comment #33 From 2010-11-16 00:50:47 PST -------
What do you mean? The title says:
"ALT attribute value not displayed when image is missing"

It's about displaying the alt text when the image isn't there. It's to fix the fact that isn't not being displayed.  All I did was clarify WHY it wasn't being displayed.  What I'm saying is completely withing reason based on this bugs original title and description.  Nothing I said is being "re-purposed".

It isn't to discus whether or not you think it should be there or not.  If you want to discus that, then you should open a new bug, because that is off topic.  You asked what the purpose would be, I gave a number of purposes.

I have added a new test case to show that the text IS being displayed in the specific case where there is a width and a height.  It SHOULD be displayed at all times.  It was already coded to display it, there's just a bug with how it is displaying it.
------- Comment #34 From 2010-11-16 09:19:42 PST -------
There are three things that need to be well understood to move forward on this bug:
- whether rendering of ALT for missing images affects accessibility at all;
- whether it is desirable for sighted users;
- what other browsers do, and what HTML5 says.

The bug doesn't have answers to all of these yet, but without the answers, it will just stay unresolved indefinitely. Here is what I got from reading the discussion here:
- there are multiple claims in this bug that it affects blind people, and fixing it is required by certain accessibility related standards. It would be great if people who posted that information could comment on how this bug affects accessibility.
- what is desirable is of course a personal preference. I know that I generally don't want any content that's normally invisible to suddenly become visible when images get lost (for example, in Internet Archive). I also want broken images to be clearly identifiable. Those pages in Internet Archive are already a mess, adding tons of text snippets from ALT attributes would just make them even less readable.
- other browsers do display ALT text for 404 images, although in different incompatible ways. HTML5 implies that it should be displayed (formally specifying what exactly browsers display it of course out of scope for it). But there are no known affected sites - the chromium bug mentions a single one which doesn't exist any more.

So, I see this as a choice between behavior that's good for users and behavior that matches other browsers, but the choice doesn't affect Web compatibility in any material way.
------- Comment #35 From 2010-11-16 10:35:51 PST -------
(In reply to comment #31)
> This bug is about displaying ALT text for missing images only - resources that the browser tried to fetch, and got HTTP code 404 Not Found. 

Alexey,

I think you have a point. The bug summary and bug description should have stated (otherwise should have been updated to reflect better what the bug was about) that the alt text is not rendered when image placeholder dimensions are insufficient (not wide enough) for the whole alt text.

> This is solely for the (questionable) benefit of sighted users, 

Alt text is useful for indexing a webpage according to many sources.

Sometimes, the url to the image has changed or was moved (excellent example of this happening is Internet Archive: WayBack Machine site): in such cases, if the image code provides an alt text, then the sighted user can still and should still be able to understand the page, continue consulting, reading the page. If the choice of the alt text is done correctly [alt text should be textual replacement, related to meaning and not a description], then the user may not even noticed that an image was not fetched and that a text replaced it.

If providing an alt text was questionably beneficial for sighted users, then I fail to see why webkit-based browsers provide a setting in the user preferences to disable image download to begin with.

> and only in cases when the site is broken anyway, having bad links to its images.

Sometimes, internet traffic can disrupt image fetching: it happens.

If you are in a place where fast download and speed of rendering page is important, like, say in a school during dinner time, then disableing image download may be a wise and defendable decision. Many bytes and http requests can be saved that way.

Alexey, there are people who are not using a fast connexion (cable or satelite). 

In some countries, internet connexion costs per Kbytes of download, while others costs per hour.

> This is how the bug was filed originally, and I don't think that it should be repurposed to track other issues with ALT that we might have. 

Not everyone (who are not original reporter) has sufficient powers to edit a bug summary, you know.

> That would be quite confusing, and can only slow down moving such issues to resolution. But if there are other issues indeed, it would be really appreciated if you could file them as separate bugs.

I invite you to read 

1-
MINI FAQ ABOUT THE ALTERNATE TEXT OF IMAGES, Written by Ian Hickson
http://hixie.ch/advocacy/alttext

2-
Side by Side WCAG vs. 508
http://jimthatcher.com/sidebyside.htm#WCAGView

3- 
Several national governments (New-Zealand, UK, USA, etc.) now require government websites (and/or entreprises doing business with them or having contracts with them) to provide proper alt text for images. 

IMO, the most important issue to fix here is related to image placeholder dimensions versus alt text (see comment #24 in this bug). An alt text *very often* does not use the same dimensions as the image; it is not likely. "A picture is worth a thousand words"

best regards, Gérard Talbot
------- Comment #36 From 2010-11-16 11:05:17 PST -------
(In reply to comment #34)

> - there are multiple claims in this bug that it affects blind people, and fixing it is required by certain accessibility related standards. It would be great if people who posted that information could comment on how this bug affects accessibility.

The National Federation of the Blind sued Target Corp. for the inaccessibility of its Web site.
http://www.webstandards.org/2007/10/05/will-target-get-schooled/

> - what is desirable is of course a personal preference. 

The web is a world of iconography, logography, ideography and pictography. An icon can be quite small (say, an image of 16px by 16px) while its textual alternative may be relatively longer. This is most likely what happened to Tab Atkins as he explained his print icon story in comment #17. 


>I know that I generally don't want any content that's normally invisible to suddenly become visible when images get lost (for example, in Internet Archive). I also want broken images to be clearly identifiable. Those pages in Internet Archive are already a mess, adding tons of text snippets from ALT attributes would just make them even less readable.

Alexey, try this: visit this page
http://www.gtalbot.org/Varia/BrowserStats.html
with image download disabled in a few browsers (in particular with Safari or Chrome) and then assess the usefulness of the page if/when image download is disabled and alt text is not rendered inline (made to ignore image placeholder dimensions instead of truncating these).

> I see this as a choice between behavior that's good for users and behavior that matches other browsers, but the choice doesn't affect Web compatibility in any material way.

"The reader of the page frankly couldn't care less if the author has made a mistake and the page is not completely available. The reader wants the information. So if an image is not available, the page should adapt. This is what alt text is designed to do." Ian "Hixie" Hickson

regards, Gérard
------- Comment #37 From 2010-11-16 11:16:21 PST -------
> If providing an alt text was questionably beneficial for sighted users, 

This is substantially different from what I said. I wasn't saying that it's never useful to sighted users, but that practical user experience can degrade if we displayed ALT when links got broken, on Internet Archive in particular.

I'd love to be proven wrong - in that case, we wouldn't face the horrible choice between user experience and compatibility with other browsers. Do you have an example of a page in Internet Archive where seeing ALT text is beneficial? This is not exactly a fair request, because I didn't provide any examples to the opposite, but it still seems appropriate to give at least one example in favor of a proposed change.

> then I fail to see why webkit-based browsers provide a setting in the user preferences
> to disable image download to begin with.

I don't know what the original reasons were, but I've been personally using it on multiple occasions to avoid paying for excessive traffic, as you described below.

>> This is how the bug was filed originally, and I don't think that it should be repurposed
>> to track other issues with ALT that we might have. 
> Not everyone (who are not original reporter) has sufficient powers to edit a bug summary, you know.

I've been saying that this bug should _not_ be repurposed in my opinion, not that someone should repurpose it :)

The issue as originally reported here is real, was reported in this exact form at least three times (see the bug I've duped a few days ago and the chromium bug), and even though it might technically be fixable in a single commit with image placeholder dimensions for disabled image loading case, discussing them in one bug only slows down resolution of both.
------- Comment #38 From 2010-11-16 11:22:42 PST -------
>> - there are multiple claims in this bug that it affects blind people, and fixing it is
>>  required by certain accessibility related standards. It would be great if people who
>> posted that information could comment on how this bug affects accessibility.

> The National Federation of the Blind sued Target Corp. for the inaccessibility of its Web site.

I fail to see how this is related to whether not displaying ALT text for broken images hampers accessibility.

It appears that this bug could have been resolved years ago if it wasn't for accessibility concerns - trying to figure out what exactly its accessibility impact can be very challenging if there is none!
------- Comment #39 From 2010-11-16 12:05:20 PST -------
(In reply to comment #37)
> we wouldn't face the horrible choice between user experience and compatibility with other browsers. 

First, let me quote what Firefox does:

"
browser.display.force_inline_alttext
True: Force broken images' alt text to be displayed inline
False (default): Show an icon if rendering in Quirks Mode and there is no alt text, or if rendering in Quirks Mode and the image has a size specified. 
"
http://kb.mozillazine.org/About:config_entries

This means that, in web standards compliant rendering mode (CSS1Compat), the alt text will be displayed inline, therefore will use/occupy as much space as required by the alt text.

E.g.:
<img src="../GRAPHICS/PNG/Safari.png" alt="Safari" height="31" width="31">
Alt text "Safari" requires more than 31px of width to be displayed.

Second, please do not do, do not follow what IE6, IE7 and IE8 does or how IE6/7/8 deals with alt text for unfetched images. I filed 2 bugs [1] on this and, as far as I know, they did nothing (a "donut" zero) in IE9.  
When "Show pictures" checkbox is intentionally unchecked in the advanced prefs setting by the user in IE6/7/8 and when the user checks "Always expand ALT text for images" checkbox in the advanced prefs setting in IE6/7/8, then, and only then, the alt text is displayed inline.

[1]: http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug29 , 
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug35


The best, safest and sound policy IMO would be to strictly follow UAAG guidelines and recommendations; I think you never can be wrong if/when a browser carefully follows UAAG guidelines (spirit, letter, checkpoints). 

regards, Gérard
------- Comment #40 From 2010-11-16 13:26:36 PST -------
(In reply to comment #38)
> >> - there are multiple claims in this bug that it affects blind people

Blind people use JAWS, speech browsers and braille browsers: if web authors do not provide alt text for images (and this is happens often; a missing alt attribute is among the top 5 validation markup errors) is not there, then it affects them.

, and fixing it is
> >>  required by certain accessibility related standards. 

There's 3 standards here: HTML 4.01 technical recommendation, WCAG 1 & 2 technical recommendation and UAAG 1.0 techical recommendation. The first two are for web authors; only UAAG applies to web browsers like Safari and Chrome.

It would be great if people who
> >> posted that information could comment on how this bug affects accessibility.
> 
> > The National Federation of the Blind sued Target Corp. for the inaccessibility of its Web site.
> 
> I fail to see how this is related to whether not displaying ALT text for broken images hampers accessibility.

I misunderstood the question. If web authors do not declare the alt attribute for image or do not provide/specify a meaningful, useful, helpful alt attribute text for images, then this affects blind people and can affect sighted users (when images are not rendered regardless of why the images are not fetched/rendered).

> It appears that this bug could have been resolved years ago if it wasn't for accessibility concerns - trying to figure out what exactly its accessibility impact can be very challenging if there is none!

If alt attribute text is not rendered inline, then this can affect web experience of sighted users.

regards, Gérard
------- Comment #41 From 2010-11-16 21:01:56 PST -------
My understanding is that if an image is not available, for one reason or another then the alt text should be displayed. In the case of a bad internet connection (I have seen plenty of those while traveling), the alt text gives me the option of deactivating image loading and then just loading specific images.

The fact that certain web sites don't provide a value for the alt tag is unfortunate, but it is a separate issue. Basically if a site is not designed for accessibility, then there is little we can do about it, but if it is then we should support the hints put in place.

For people who would rather not see the alt text, for whatever reason, this could be relegated to a 'preference', but in the main scenario we should be displaying the text, when the image can not be loaded.

I haven't looked at the specifications recently, so I can't say what they suggest.
------- Comment #42 From 2010-11-16 23:17:58 PST -------
Well, the only non-webkit browsers that matter are Opera and FF, and they both show the alt text.
------- Comment #43 From 2011-03-22 09:27:36 PST -------
Is anyone going to bother with this, or will this important problem simply be ignored?  It's been here over half a decade and 50 people have stared it on the chromium bug.
------- Comment #44 From 2011-05-20 15:35:04 PST -------
ref BR-8046, ou1cimx1#764288
------- Comment #45 From 2011-05-23 16:05:54 PST -------
I'll take a look at this one.

I noticed a couple of things so far.

The code makes an attempt under some situations (src="") to size to show the
alt text.  If I change the code to include the text margins, then it displays.

bool RenderImage::setImageSizeForAltText(CachedImage* newImage /* = 0 */)
{
...
#if 1
        // Add text size to padding.
        imageSize.expand(textSize.width(), textSize.height());
#else
        imageSize = imageSize.expandedTo(textSize);
#endif


Use of title attribute when alt is missing seems wrong.

String HTMLImageElement::altText() const
{
    // lets figure out the alt text.. magic stuff
    // http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html#altgen
    // also heavily discussed by Hixie on bugzilla
    String alt = getAttribute(altAttr);
    // fall back to title attribute
    if (alt.isNull())
        alt = getAttribute(titleAttr);
    return alt;
}
------- Comment #46 From 2011-06-03 13:54:18 PST -------
Created an attachment (id=95958) [details]
Siimple HTML test cases with alt text with and without size info

Includes alt_image01.html (without size info) and alt_image01_size.html (with size info)

Internet Explorer

  Shows a border around broken image icon and alt text for img with
  empty src attrubyte or not found content.

  Does not use title attribute if alt attribute is missing.

Firefox

  Shows alt text for img with empty src or not found
  content.  No border.  Broken image icon show if no alt text.

  When I define a large width, and height, shows a border around a
  broken image icon and alt text

  Does not use title attribute if alt attribute is missing.

All WebKit based Browsers. Safari, Chrome, WebKit Gtk Browser, WebKit
Qt Test Browser.

  As has been pointed out before alt text is not displayed due to sizing
  issues.

  Shows a border (empty box) for empty src , and shows a border around
  around an broken image icon for not found content.

  When I define a large width, and height, shows a border around the
  alt text for no src URL, and shows a border around around an broken
  image and the alt text for a nonexistant src URL.

  Broken image and alt text show as image centered in area with alt text
  in upper left corner of area.

  The title attribute is used if alt attribute is missing.
------- Comment #47 From 2011-06-06 11:28:57 PST -------
Created an attachment (id=96099) [details]
Example patch of corrected alt text sizing

The question is where to go from here.  As a first cut I would suggest
changing code to show the border box, icon followed by alt text if
available.  Note this will be different from the current code which
displays the icon in the middle of the area and alt text in the upper
left corner of the area (when there is enough room). This would
require changing the sizing code.  Attached is a patch that shows a
1st cut at that.  It is just for example and I will be running it through
the layout tests.

Tricky parts for a more complete solution will be doing the correct
thing when width/height dimensions are specified, and deciding what to
do visually.  Should we be using the title attribute as an alternative
to no alt attribute specified?  When should we display border box, and icon
along with alt text?

P.S.  As far as I can tell, the Omnigroup solution looks like they just show
show a broken image instead of all the border, icon, alt text
rendering code in RenderImage::paintReplaced.
------- Comment #48 From 2011-06-20 12:35:45 PST -------
Created an attachment (id=97839) [details]
Fix the image rendering sizing so that broken image icon and alt text will be displayed when they are avaiable

This is a fairly big issue so I am taking a phased approach.
This 1st submittal is just to get the current code to work as it
I think it was intended.  I basically attempted to fix the sizing
code so that the alt text could be displayed.

Once design decision I did make was to show the border box, with the
broken image icon in the upper left corner followed by the alternate text.
The original code would show the border box with the broken image icon
in the center and the alternate text in the upper left corner.

I had to redo the results of several tests now that the sizing and display
of alt text are different.  I only updated the results on the platform
I have convenient access to (QtWebkit Linux).  Please let me know if
I need to update results on other platforms.  I will have to see if I
can get access to them.

This is a large patch, but it is mostly a couple of new tests and new
results files.
------- Comment #49 From 2011-06-20 12:55:07 PST -------
(From update of attachment 97839 [details])
Attachment 97839 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/8908595

New failing tests:
fast/encoding/utf-16-little-endian.html
fast/dom/HTMLImageElement/image-alt-text.html
fast/dom/inner-text.html
fast/block/float/015.html
tables/mozilla/bugs/bug2962.html
editing/pasteboard/drag-image-to-contenteditable-in-iframe.html
fast/lists/inlineBoxWrapperNullCheck.html
editing/execCommand/insertImage.html
tables/mozilla/bugs/bug56201.html
fast/dom/HTMLInputElement/input-image-alt-text.html
fast/forms/input-value.html
fast/encoding/utf-16-big-endian.html
fast/dom/34176.html
fast/borders/rtl-border-05.html
------- Comment #50 From 2011-06-20 12:55:15 PST -------
Created an attachment (id=97843) [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: Chromium  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
------- Comment #51 From 2011-06-21 11:08:58 PST -------
(In reply to comment #49)

Most of these can be explained by my change.  Need to update 
expected results on other platforms.  First, I will investigate
fast/forms/input-value.html since I don't understand why it is failing


Expected results updated on Qt Linux due to my change.
Need to update on other platforms.

  fast/encoding/utf-16-little-endian.html
  fast/encoding/utf-16-big-endian.html
  fast/lists/inlineBoxWrapperNullCheck.html
  fast/dom/HTMLInputElement/input-image-alt-text.html
  fast/dom/HTMLImageElement/image-alt-text.html
  fast/dom/inner-text.html
  fast/block/float/015.html
  tables/mozilla/bugs/bug2962.html
  tables/mozilla/bugs/bug56201.html

Need to investigate. Odd results.
Seems wrong on Qt Linux. 784x692 instead of 800x600.

  fast/forms/input-value.html

No Qt Linux results. Change do to my change.
Need to update on other platforms.
  fast/dom/34176.html
  fast/borders/rtl-border-05.html
  editing/pasteboard/drag-image-to-contenteditable-in-iframe.html

Fails on Qt Linux and other platforms due to my change.
Forgot to add new expected result on Qt.
Need to update on Qt and other platforms.
  ./editing/execCommand/insertImage.html
------- Comment #52 From 2011-06-21 11:39:57 PST -------
(In reply to comment #51)
> (In reply to comment #49)
This test failure is also due to my changes.
Test in Qt Skipped list.
  fast/forms/input-value.html
------- Comment #53 From 2011-06-24 10:55:31 PST -------
Created an attachment (id=98509) [details]
Fix the image rendering sizing so that broken image icon and alt text will displayed


I redid the original patch with add the tests that changed behavior because
of this change to the Skipped lists on other platforms than Qt Linux.
My understanding is that this is a valid to do until those tests
can be updated on the respective platforms.

I gave it my best guess as to which Skipped lists needed to
changed and how to skip tests in chromium/text_expectations.txt.
I welcome any advice on how to do this better.

Again, this is a big patch, but it is mostly new and updated
test results.
------- Comment #54 From 2011-06-24 12:15:09 PST -------
This likely needs Hyatt review (he's on vacation right now, but given the age of this bug, it's hopefully not a big problem).
------- Comment #55 From 2011-12-18 02:07:21 PST -------
(In reply to comment #45)
> Use of title attribute when alt is missing seems wrong.

Wrong how?
------- Comment #56 From 2011-12-18 10:16:07 PST -------
(In reply to comment #55)
> (In reply to comment #45)
> > Use of title attribute when alt is missing seems wrong.
> 
> Wrong how?

The @title attribute represents advisory information for the element, such as would be appropriate for a tooltip. The @alt attribute represents an appropriate replacement for the image.

So, when an image cannot be displayed, alternate text must be displayed in the place of the image.

Also, please see this:
http://a11ybugs.org/bug-3.php
------- Comment #57 From 2011-12-18 10:41:37 PST -------
(In reply to comment #56)
> (In reply to comment #55)
> > (In reply to comment #45)
> > > Use of title attribute when alt is missing seems wrong.
> > 
> > Wrong how?
> 
> The @title attribute represents advisory information for the element, such as would be appropriate for a tooltip. The @alt attribute represents an appropriate replacement for the image.
> 
> So, when an image cannot be displayed, alternate text must be displayed in the place of the image.
> 
> Also, please see this:
> http://a11ybugs.org/bug-3.php

Yes, however, @title has long been used as a repair text substitute for @alt (see UAAG etc).
------- Comment #58 From 2011-12-18 11:50:09 PST -------
(In reply to comment #57)
> Yes, however, @title has long been used as a repair text substitute for @alt (see UAAG etc).

IE6 and IE7 used title attribute as a text substitute for missing alt but that was an extension of the spec. This stopped with IE8.

I have already provided links (references, tests) to WAI, UAAG in comment 10, comment 12 and comment 24.

Title attribute should do one thing and alt attribute should do another thing. 
The main problem with browsers (IE9+, Opera 11.60, Chrome 16.0.912.63, Safari 5.1.2, Konqueror 4.7.4) right now is that alt text is rendered *_within_* author-specified image placeholder dimensions (causing alt text to be cut off, truncated) while the spec says that the user agent should allow the user to choose how the alt text is rendered: either *_within_* or by ignoring author-specified image placeholder dimensions.

Firefox ignores author-specified image placeholder dimensions by default and renders alt text inline. That is best (for accessibility). That is what Ian Hickson recommends.

regards, Gérard Talbot
------- Comment #59 From 2011-12-18 12:09:11 PST -------
> Yes, however, @title has long been used as a repair text substitute for @alt (see UAAG etc).

You have an opportunity to correct past mistakes.

Also, 600+ people have signed a petition asking WebKit to implement rendering of @alt based on Firefox implementation: http://a11ybugs.org/

This bug has been in this bug database since 2005. Please, let's fix it now.
------- Comment #60 From 2011-12-18 13:13:28 PST -------
(In reply to comment #59)
> > Yes, however, @title has long been used as a repair text substitute for @alt (see UAAG etc).
> 
> You have an opportunity to correct past mistakes.
> 
> Also, 600+ people have signed a petition asking WebKit to implement rendering of @alt based on Firefox implementation: http://a11ybugs.org/

1. I don't think that petition has much bearing on my question to be honest.

2. Providing a @title and not providing an @alt is not a mistake per the current HTML5 draft. One of the reasons the WG let this provision stand was that user agents could provide access to @title when @alt is missing:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html
------- Comment #61 From 2011-12-18 13:42:51 PST -------
(In reply to comment #6)
>  how to render missing images with alt text
> (b) when their dimensions are not specified
> In the latter case, how do you determine what size to use for the image?

Render the alt text as inline, in which case width and height do not apply: the text will use as much space it requires and needs. 

If you decide not to render the alt text as inline, then sizes (width and height) are entirely user-agent dependent and arbitrary and you may have exactly what happens in this bug: truncated alt text and people filing bug reports.

(In reply to comment #7)
> the size of the image should be 300px x 150px as specified by the CSS spec. 
> See:
> 
> http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width
> http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

What you suggest would apply for <iframe> and <img> withOUT an intrinsic ratio and with a css 'width' of auto; this is not the case for images and not possible for images. Images have (one of the 3 following) an intrinsic ratio or an intrinsic width or an intrinsic height.

If you define an <iframe> without a width or height attribute specification and with css 'width' as auto, then a particular statement of
section 10.3.2
http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width 
is going to apply.

Replaced elements does not imply an alt text: the 2 are different matters.
A replaced element by definition has an attribute like data or src. <object>, <iframe> and <img> are inline replaced elements. <frame> is a block level replaced element.
Replace element definition:
http://www.w3.org/TR/CSS21/conform.html#defs

regards, Gérard
------- Comment #62 From 2011-12-18 14:09:38 PST -------
(In reply to comment #60)
> (In reply to comment #59)
> > > Yes, however, @title has long been used as a repair text substitute for @alt (see UAAG etc).
> > 
> > You have an opportunity to correct past mistakes.
> > 
> > Also, 600+ people have signed a petition asking WebKit to implement rendering of @alt based on Firefox implementation: http://a11ybugs.org/
> 
> 1. I don't think that petition has much bearing on my question to be honest.

You asked "Wrong how?". Title is for additional information. Alt is for textual replacement, textual substitution in case of user agent capability, internet traffic issues, wrong linkage of image, user settings. The 2 serve distinct, separate goals, purposes. Conditional content may be rendered via different mechanisms according to WAI and UAAG.

The petition, albeit not perfectly clear (683 people voted for all 3 bugs or only 1 of the 3), indicate interests and "If a bug is getting a lot of public attention, the priority may be moved up" [1]. I clearly remember voting for this bug and even said so in comment 10. Now that the voting system has been removed, the petition somehow replaces it.


> 2. Providing a @title and not providing an @alt is not a mistake per the current HTML5 draft. 

If one does not provide an alt attribute for an image, then such situation has nothing to do with this bug report.

And, yes, HTML5 draft, not a PR, may allow absence of alt: when an alt text is provided, then what is HTML5 draft saying? Ian Hickson is the author behind WHATWG HTML5 and his position on how to render alt has been given by himself in comment 8. 

> One of the reasons the WG let this provision stand was that user agents could provide access to @title when @alt is missing:
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html

That 2011Apr/0451.html is a long document with multiple inter-linked documents and it does not address what this bug report is really about: when an alt text is provided for an img, then author-specified image placeholder dimensions should not interfere with alt text's complete rendering (as inline).

[1] Prioritizing Web Kit Bugs in Bugzilla 
http://www.webkit.org/quality/bugpriorities.html

regards, Gérard
------- Comment #63 From 2011-12-18 14:26:10 PST -------
(From update of attachment 98509 [details])
All the magic numbers should be explained through constants and not via comments.

And this patch needs tests for all the cases that were discussed in the comments (explicit size via image attribute, CSS, text that fits, text that wraps, etc).
------- Comment #64 From 2011-12-18 17:02:08 PST -------
(In reply to comment #62)
> > 1. I don't think that petition has much bearing on my question to be honest.
> 
> You asked "Wrong how?". Title is for additional information. Alt is for textual replacement, textual substitution in case of user agent capability, internet traffic issues, wrong linkage of image, user settings. 

In the absence of @alt, @title is also for textual replacement. See UAAG, HTML5 etc.

> The petition, albeit not perfectly clear (683 people voted for all 3 bugs or only 1 of the 3), indicate interests and "If a bug is getting a lot of public attention, the priority may be moved up" [1]. I clearly remember voting for this bug and even said so in comment 10. Now that the voting system has been removed, the petition somehow replaces it.

@title isn't mentioned in the petition and wasn't mentioned in this bug until comment #45.

I strongly agree with modifying WebKit to display @alt text inline when @alt is present.

I'm questioning the rationale for making an *additional change* to not display @title in the same way.

> > 2. Providing a @title and not providing an @alt is not a mistake per the current HTML5 draft. 
> 
> If one does not provide an alt attribute for an image, then such situation has nothing to do with this bug report.

I think you're mistaken. Currently WebKit shows @title inline when @alt is missing. Comment #45 is proposing changing that behavior.

> And, yes, HTML5 draft, not a PR, may allow absence of alt: when an alt text is provided, then what is HTML5 draft saying? Ian Hickson is the author behind WHATWG HTML5 and his position on how to render alt has been given by himself in comment 8. 

Ian's earlier published personal opinions to not have the weight of WHATWG and W3C. I'm not sure how many cycles he spends updating his earlier publications to match recent web standards drafts, either.

> > One of the reasons the WG let this provision stand was that user agents could provide access to @title when @alt is missing:
> > http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html
> 
> That 2011Apr/0451.html is a long document with multiple inter-linked documents and it does not address what this bug report is really about: when an alt text is provided for an img, then author-specified image placeholder dimensions should not interfere with alt text's complete rendering (as inline).

It /does/ address the change to @title proposed in Comment #45. If the patch changes behavior as proposed in Comment #45 then this discussion is indeed relevant here.
------- Comment #65 From 2011-12-18 17:07:08 PST -------
Looking at the patch, especially the test case "image-alt-text-with-title.html", it looks like for the moment it preserves the behavior of showing @title inline when @alt is missing.
------- Comment #66 From 2011-12-18 17:37:13 PST -------
(In reply to comment #64)
> (In reply to comment #62)
> > > 1. I don't think that petition has much bearing on my question to be honest.
> > 
> > You asked "Wrong how?". Title is for additional information. Alt is for textual replacement, textual substitution in case of user agent capability, internet traffic issues, wrong linkage of image, user settings. 
> 
> In the absence of @alt, @title is also for textual replacement. See UAAG, HTML5 etc.


This bug report is not about the absence of alt attribute. 

This bug report has nothing to do with the absence of alt attribute. 

This bug report has been utterly explained, commented, testcase-ed, backed up with quotes from the specifications.



> 
> > The petition, albeit not perfectly clear (683 people voted for all 3 bugs or only 1 of the 3), indicate interests and "If a bug is getting a lot of public attention, the priority may be moved up" [1]. I clearly remember voting for this bug and even said so in comment 10. Now that the voting system has been removed, the petition somehow replaces it.
> 
> @title isn't mentioned in the petition and wasn't mentioned in this bug until comment #45.


This bug report has not about the title attribute. 

This bug report has nothing to do with the presence or the function of the title attribute when alt attribute is missing (or empty).



> 
> I strongly agree with modifying WebKit to display @alt text inline when @alt is present.
> 
> I'm questioning the rationale for making an *additional change* to not display @title in the same way.


Title is displayed in a tooltip right now. Title displayed (or not displayed) in the same way would mean another bug report. That would be outside this bug report.


> 
> > > 2. Providing a @title and not providing an @alt is not a mistake per the current HTML5 draft. 
> > 
> > If one does not provide an alt attribute for an image, then such situation has nothing to do with this bug report.
> 
> I think you're mistaken. Currently WebKit shows @title inline when @alt is missing. Comment #45 is proposing changing that behavior.
> 


If comment 45 is proposing such behavior, then it is not what this bug report is about. I think, in comment 45, it was noticed what IE8+ does:


"
The alt attribute is no longer displayed as the image tooltip when the browser is running in IE8 Standards mode. Instead, the target of the longDesc attribute is used as the tooltip if present; otherwise, the title is displayed. The alt attribute is still used as the Microsoft Active Accessibility name, and **the title attribute is used as the fallback name only if alt is not present**. 
"
http://msdn.microsoft.com/en-us/library/cc288472%28v=VS.85%29.aspx#access



I have answered explanations carefully backed up by the spec (and I quoted and linked the spec) with regards to the important questions relevant to this bug report which were asked in comment 6.

There should be only 1 bug report for one precisely defined issue.

What exactly can or should happen when alt attribute is missing and title attribute is provided is not what this bug report is about.

Gérard
------- Comment #67 From 2011-12-18 17:47:12 PST -------
Gérard, Benjamin; unless you plan to make a patch, I think it is useless to discuss all that here, it should be discussed on the W3C or WHATWG.
------- Comment #68 From 2011-12-18 17:56:21 PST -------
(In reply to comment #67)
> Gérard, Benjamin; unless you plan to make a patch, I think it is useless to discuss all that here, it should be discussed on the W3C or WHATWG.

Those are the right places to discuss what the specs should say, but that's not my purpose here. I'm just trying to understand the patcher's intentions and his reasoning. In comment #45 he indicated he wanted to stop showing @title. In comment #47 he asks "Should we be using the title attribute as an alternative to no alt attribute specified?" The patch as it stands adds a test case for using @title, but then he says "This 1st submittal is just to get the current code to work as it I think it was intended" in comment #48. Other people's contributions are welcome obviously, but mainly I just wanted to hear from the patcher (Joe) …
------- Comment #69 From 2012-04-27 08:40:49 PST -------
It's crazy that nothing's been done on this for almost 7 years. Please, can something, ANYTHING be done here? This is the first browser bug i've actually spent a little time to read up on, and it's more than a little disconcerting that we can't push out anything because of the lack of agreement. At the least can't we mirror a browser that handles this better (at all)?

I've got an idea of how it should be handled if you'd rather:

Image example: <img src="blah.png" alt="this is alt" title="this is title" />

 - If everything's all good, show the image, and on hover show "this is title". Easy.
 - If images are disabled or broken for any reason, don't show the image (obviously), and in it's place show inline text that says "this is alt" that uses the styling of whatever container it's in. Also, when that is hovered over, show "this is title".

Also, the title and alt attributes shouldn't have anything to do with one another. If title isn't there, nothing happens when the image (or alt text if image is gone) is hovered. And same goes for alt text. If there's no alt text but there is title text, nothing shows when the image is missing, but if you hover over it, you'll see the title text. If that seems weird, just note that it's up to the web developer to make sure that stuff works well, and you probably shouldn't have just a title without an alt value.

Can we all agree that 99% of the time when images are disabled or broken the entire site looks a little wonky or off? Good, because now we don't have to worry about those edge cases where the missing image is a tiny icon or thumbnail and the alt text is equivalent to the first half of "War and Peace". :P

TL;DR - Doing something is better than doing nothing.
------- Comment #70 From 2012-08-12 09:18:55 PST -------
https://bugzilla.mozilla.org/show_bug.cgi?id=41924 is worth a read. Joe's patch seems to be in the spirit of http://hixie.ch/specs/alttext rather than current Firefox treatment of broken images, which does not display a broken image icon at all.

Is it only lack of testcases blocking Joe's patch now? Benjamin, would you r+ it with more testing?
------- Comment #71 From 2012-08-12 14:12:21 PST -------
(In reply to comment #70)
> https://bugzilla.mozilla.org/show_bug.cgi?id=41924 is worth a read. Joe's patch seems to be in the spirit of http://hixie.ch/specs/alttext rather than current Firefox treatment of broken images, which does not display a broken image icon at all.
> 
> Is it only lack of testcases blocking Joe's patch now? Benjamin, would you r+ it with more testing?

Sorry, it has been a long time, so I am out of touch with all the details related to this issue.

I have nothing against the feature per se. If there is a good patch, I'll read everything again and r+ if possible.
------- Comment #72 From 2012-08-31 05:56:49 PST -------
Here's a thought: If it is totally impossible to simply follow the utterly clear and unambiguous html standards after 7 years of debate, how about producing a plugin poor fools like me can use to automatically replace images with the alt text on web sites we have absolutely no control over which are missing all their images and where the only way they are usable is if we can see the dadgum alt text.
------- Comment #73 From 2013-04-01 19:32:50 PST -------
Created an attachment (id=196058) [details]
Basically, we can display the alt text value if there is the efficient space.

Webkit already has the efficient space to draw the alt text value.
Before painting the text, it subtracts 2px from the clientWidth" (the comment says)
But "clientWidth" doesn't include the margin, border, padding and outlines. 
Using this simple patch, (just removing the subtraction) we can see the alt text in many cases.
First of  all, how about this?
------- Comment #74 From 2013-04-01 20:25:12 PST -------
kyounga, any improvement is good. However, what is required is the ability to render alt text that is not contrained by image dimensions as implemented in Firefox.
------- Comment #75 From 2013-04-02 02:00:52 PST -------
(In reply to comment #74)
> kyounga, any improvement is good. However, what is required is the ability to render alt text that is not contrained by image dimensions as implemented in Firefox.

I'm not sure the FireFox's behaviour is that right.
whatever, I think my patch can be a first step. It just removes the incorrect code.
------- Comment #76 From 2013-04-02 09:29:59 PST -------
(From update of attachment 196058 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=196058&action=review

> Source/WebCore/ChangeLog:9
> +        Test: fast/dom/HTMLImageElement/image-alt-text.html

If this test can be used to validate this fix, then why doesn’t this patch include changes to the test results?
------- Comment #77 From 2013-04-02 17:18:49 PST -------
(In reply to comment #76)
> (From update of attachment 196058 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=196058&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        Test: fast/dom/HTMLImageElement/image-alt-text.html
> 
> If this test can be used to validate this fix, then why doesn’t this patch include changes to the test results?

This patch does not change the render tree.
It just display the additional text. ("Success")
Webkit has already made the render tree  calculating the text's width. It didn't just display the text. 
So, I thought I don't need change the expected result .txt file.

Saying the each platform own expected result .png file,
Should I make the new expected result .png file on each platform?
The images include just one "Success" text. the test requires twice "Success". 
With this patch, webkit could display twice "Success".
If there is a way to create new expected result image file for each platform, please let me know.
------- Comment #78 From 2013-04-03 01:50:42 PST -------
(In reply to comment #76)
> (From update of attachment 196058 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=196058&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        Test: fast/dom/HTMLImageElement/image-alt-text.html
> 
> If this test can be used to validate this fix, then why doesn’t this patch include changes to the test results?

fast/dom/HTMLImageElement/image-alt-text.html & fast/dom/HTMLInputElement/input-image-alt-text.html were fixed via Bug 94198.