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.
Created attachment 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.
<rdar://problem/3384556> Should display ALT attribute of IMG tags in missing-image case also
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.
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.
*** Bug 5753 has been marked as a duplicate of this bug. ***
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?
(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
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. :-)
*** Bug 16253 has been marked as a duplicate of this bug. ***
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
*** Bug 17967 has been marked as a duplicate of this bug. ***
WAI and UAAG 1.0 testcase: http://www.w3.org/WAI/UA/TS/html401/cp0203/0203-IMG.html
The Chromium Bug is: http://code.google.com/p/chromium/issues/detail?id=773
http://code.google.com/p/chromium/issues/detail?id=773
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?
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.
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.
I'm unassigning Adele to get more feedback. Feel free to reassign if it's inappropriate.
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.
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.
Created attachment 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.
Is there any updates on this or any plans to fix this?
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
(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
Seriously? 5 years? wow.
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?
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.
*** Bug 34919 has been marked as a duplicate of this bug. ***
> 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.
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.
> 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.
Created attachment 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.
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.
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.
(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
(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
> 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.
>> - 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!
(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
(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
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.
Well, the only non-webkit browsers that matter are Opera and FF, and they both show the alt text.
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.
ref BR-8046, ou1cimx1#764288
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; }
Created attachment 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.
Created attachment 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.
Created attachment 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 on attachment 97839 [details] Fix the image rendering sizing so that broken image icon and alt text will be displayed when they are avaiable 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
Created attachment 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
(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
(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
Created attachment 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.
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).
(In reply to comment #45) > Use of title attribute when alt is missing seems wrong. Wrong how?
(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
(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).
(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
> 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.
(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
(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
(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 on attachment 98509 [details] Fix the image rendering sizing so that broken image icon and alt text will displayed 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).
(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.
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.
(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
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.
(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) …
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.
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?
(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.
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.
Created attachment 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?
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.
(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 on attachment 196058 [details] Basically, we can display the alt text value if there is the efficient space. 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?
(In reply to comment #76) > (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? 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.
(In reply to comment #76) > (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? fast/dom/HTMLImageElement/image-alt-text.html & fast/dom/HTMLInputElement/input-image-alt-text.html were fixed via Bug 94198.
*** Bug 137428 has been marked as a duplicate of this bug. ***
Comment on attachment 196058 [details] Basically, we can display the alt text value if there is the efficient space. 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. > > fast/dom/HTMLImageElement/image-alt-text.html & fast/dom/HTMLInputElement/input-image-alt-text.html were fixed via Bug 94198. The best way to make a test is to use a reference test. That's a test with
*** This bug has been marked as a duplicate of bug 94198 ***