Closed Bug 5764 Opened 25 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: 25 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: 25 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.