Version: (using KDE KDE 3.0.3) Installed from: Slackware Packages OS: Linux When images are disabled in Konqueror, khtml attempts to supply "placeholders" of the images' size for the unloaded images where the <IMG> tag specifies a size. However, when no size is specified in the <IMG> tag, no visable placeholder is provided. This behaviour is undesirable because images (even without a size specified) may be used as links, form submit buttons, etc. Furthermore, when there is no visable placeholder supplied, it is impossible to "right click" and see konqueror's pop-up menu reguarding the image(s). It is desired (from my point of view) that if no image size is specified and images are off, khtml/konqueror blocks off a small (10x10, 15x15, or 20x20 pixel) area to indicate that an image was there. This area should also be clickable in case. If an image has alternate text, the placeholder should at least be large enough to make the alternate text visable. Example pages showing the current behavior: http://www.moderntales.com (although they supply text & image links, the image links are unusable unless the images are loaded), etc.
The next to last paragraph, second sentance should read: This area should be clickable in case it is being used as a link, form submit button, Javascript action, etc.
those images should get the size, we need for the alt="" text.
Websites are not navigatable either, if you have set to disable images and there are hyperlinks that are directed to by images without hypertext. Konqueror desperately needs correct-sized image placeholders.
*** Bug 49910 has been marked as a duplicate of this bug. ***
Test case for duplicate bug #47956: http://www.fish.zetnet.co.uk/47956-test.html
> If an image has alternate text, the placeholder should at least be > large enough to make the alternate text visable. Then this bug must be a duplicate of bug 170069 or bug 170069 is a duplicate of this bug. Either way, I don't mind. In bug 170069, I have testcases, links to references, excerpts of spec (UAAG 1.0) and examples of how other browsers implement (or try to implement) this. Right now, Firefox 2.x, Firefox 3.x, Seamonkey 1+ (and other Gecko-based browsers) and Amaya 9+ implement this as proposed by Ian "Hixie" Hickson. For countless accessibility reasons, image placeholder dimensions should be overruled, ignored when image is unavailable, not loaded due to user settings or network problem or wrong path/filename of image or internet traffic. regards, Gérard
Konqueror formats alt attribute text as expected (font-size is correct) in this test: http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/FormattedAlternateText.html but the size (width) of the alt attribute text is insufficient. Please note that Firefox and Gecko-based browsers probably have the best implementation of alt attribute value when the image is unavailable (whatever the reasons: user settings, network, internet traffic, wrong path/filename of image) and regardless of "author-specified geometry" of image. (The standards compliant rendering mode will force alt attribute value to be rendered inline). -------------- Firefox 2, Firefox 3.x, Seamonkey (and other Gecko-based browsers) implementation: browser.display.force_inline_alttext Boolean 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#Browser. What that also means (and this is very important) is that, by default, the alt text will be displayed inline whenever Firefox is triggered in standards compliant rendering mode. So author-specified geometry of an unavailable image will be ignored when rendering the alt attribute value in standards compliant rendering mode. regards, Gérard
I think bug 170069, bug 48458 and bug 276839 should merge into 1 single bug report. Gérard
Bug 158249, bug 170069, bug 48458 and bug 276839 should merge into 1 single bug report. Gérard
*** This bug has been marked as a duplicate of bug 158249 ***