Closed Bug 5764 Opened 26 years ago Closed 25 years ago

Algorithm for finding alternate text for broken images

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: elig, Assigned: buster)

References

(
URL
)

Details

* TITLE/SUMMARY Image name is now being displayed as ALT text when image can't be loaded * STEPS TO REPRODUCE 0) Launch Apprunner 1) View http://www.prometheus-music.com/gecko/imagelink.html (pasted below as text snippet) * RESULT - What happened Rather than displaying a broken image icon, the image name is now being displayed. (New as of this week's builds.) Most webmasters don't choose image names with the intention of people actually reading them, resulting in incomprehensible verbiage like "img_foo_bar" over pages. - What was expected Behavior equivalent to Communicator 4.5 or IE 5 (they display a broken image icon). Also, please note related bug comments in 3268. * REGRESSION - Occurs On Mac OS, Linux, Win32 (NT 4 SP3) Apprunner (4.29.99 PM optimized build) - Doesn't Occur On Communicator 4.6 (4.28.99 build, Mac OS) Internet Explorer 5 (RTM, Win32) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.
URL: http://www.prometheus-music.com/gecko...
QA Contact: 4144 → 1698
* HTML SNIPPET <HTML> <IMG SRC = "foo_bar_image.gif"> </HTML>
Just to short-circuit the discovery process, I'm passing on this posting from troy@netscape.com in n.p.m.layout.checkins: news://news.mozilla.org/37141582.2D5177FA%40netscape.com I won't miss the 'broken image', but there are some refinements that will need to be made (particularly in dealing with the egregiously common abuse of ALT -- <img src="space.gif" height=1 width=1 alt="This is a spacer image">).
*** Bug 5830 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
This is correct behavior as described in bug 1994, 2534, 4354, and others. Marking this as WONTFIX as that was the resolution for those earlier bugs...
Status: RESOLVED → REOPENED
Re-opening. Those bugs predominantly didn't deal with the scenario in which no ALT text was provided, and moreso, whether this won't be fixed is for the engineer to decide.
Resolution: WONTFIX → ---
Moreso, despite of the specification says, the current implementation differs from what users currently expect, and in a fashion that's confusing to those who don't know HTML from a Start menu. Even if we move to be specification compliant, I think this should be included as an emulated quirk, if it's possible to include it in quirks mode.
Specifically, per bug #2534 (thanks to cpratt for pointing this out), troy says: "Since there is no "alt" text probably nothing should be displayed" However, with no alt text, we're displaying the file name. *That's* what this bug is about.
Group: netscapeconfidential?
From the notes to bug 4354: "Anyway, the correct thing to do, which we don't do yet but will, is to display the value of the ALT text instead. If there is no ALT text we display the image filename (minus the extension). This is per the HTML 4 spec..." ... which leads me to believe this is another WONTFIX. beard? troy?
Why is this bug marked as "Netscape confidential only"?
Group: netscapeconfidential?
Good question; I'd assume user (or user interface) error. Thanks for pointing that out.
A test page for this will be written some time this millenium. In the meantime, here is a detailed description of the what the behaviour should be, IMHO: 1. Prior to download attempt, if download attempt is going to be attempted (i.e., not if images are disabled): 1. If image size (width&height) is given (eg, from HTML attributes or from applicable CSS properties), then leave a transparent gap of the right size where the image will end up, using CSS2 replaced content rules as appropriate. 2. If the image size is _not_ specified, then draw in the alternate representation as described below. 2. After download attempt: 1. If image is valid and good and supported, then: 1. If the image size is given (see criteria above) then place the image (stretched as required) into the space set aside. 2. If the image size is not given, then: 1. If the image size is given by the image itself, then set use that as the given image size, then insert it using CSS replaced content rules. 2. If the image has no intrinsic image size, then behaviour at this step is undefined. Sorry. 2. If image is not valid, then insert the alternative text into the document as if it were generated content, removing any placeholder gap. The alternative text should be generated using these rules: 1. If alt attribute is present, then use that (even if empty). 2. If alt attribute is _not_ present, then the document is invalid, but... 1. If title attribute is present, then use that. 2. Otherwise, if the name attribute has been specified (eg, on INPUT elements), its value should be used as alternate text. 3. Otherwise, if the image is fora submit or reset button then the value of the type attribute should be used as alternate text. 4. Otherwise, if HTTP headers provide title information when the included object is retrieved, this information should be used as alternate text. 5. Otherwise, if the included object contains text fields (e.g., GIF images contain some text fields), information extracted from the text fields should be used as alternate text. Since user agents may have to retrieve an entire object first in order to extract textual information, user agents may adopt more economical approaches (e.g., content negotiation). This particular case is probably only useful in the case of images being disabled, but could also be useful if the image type is generally supported, but the specific encoding is not. 6. Otherwise, in the absence of other information, user agents should use the file name (minus the extension) as alternate text. See also: http://qsilver.queensu.ca/~buslib/mozilla.html http://qsilver.queensu.ca/~buslib/mozilla-alt.html
This bug is one of many related to alternate text of images. All these bugs have been marked. To find related bugs, search the description field for the string "[ALT]".
Assignee: beard → kmcclusk
Status: REOPENED → NEW
This bug seems more layout oriented than compositor, or I suppose GFX image handling.
Here is the promised test page: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html BTW, I would suggest this bug be reassigned to layout.
Component: Compositor → Layout
Ian's wish is my command...reassigning to layout...
Assignee: kmcclusk → rickg
Rick I am reassigning to you since it is a layout issue, not a gfx or compositor issue.
THough I expect I'll have to fix this, I'm going to store it with Kipps stuff for now (since its a kipp issue), until I free up to take on layout issues.
Assignee: rickg → kipp
Summary: Image name displayed as ALT text when image can't be loaded → Algorithm for finding alternate text for broken images
Target Milestone: M15
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Depends on: 1994
Resolution: --- → WONTFIX
It's difficult to tell anymore exactly what this bug is about, but it seems to be unhappiness about how we handle (or will handle once I turn it back on) broken images. So it's clear to everyone, we will be doing what the HTML4 spec says we should do. That means _no_ broken icon, and displaying of the alt (or something appropriate) instead. And _no_ compatibility mode, either. Ian, please use bug #1994 for IMG alt text related stuff
Status: RESOLVED → VERIFIED
Target Milestone: M15
Ok. Verifying.
*** Bug 16623 has been marked as a duplicate of this bug. ***
Depends on: 75185
No longer depends on: 1994
You need to log in before you can comment on or make changes to this bug.