Closed
Bug 5764
Opened 26 years ago
Closed 26 years ago
Algorithm for finding alternate text for broken images
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: elig, Assigned: buster)
References
()
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.
Reporter | ||
Updated•26 years ago
|
QA Contact: 4144 → 1698
Reporter | ||
Comment 1•26 years ago
|
||
* HTML SNIPPET
<HTML>
<IMG SRC = "foo_bar_image.gif">
</HTML>
Comment 2•26 years ago
|
||
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">).
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...
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 5•26 years ago
|
||
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.
Reporter | ||
Updated•26 years ago
|
Resolution: WONTFIX → ---
Reporter | ||
Comment 6•26 years ago
|
||
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.
Reporter | ||
Comment 7•26 years ago
|
||
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.
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?
Comment 9•26 years ago
|
||
Why is this bug marked as "Netscape confidential only"?
Reporter | ||
Updated•26 years ago
|
Group: netscapeconfidential?
Reporter | ||
Comment 10•26 years ago
|
||
Good question; I'd assume user (or user interface) error. Thanks for pointing
that out.
Comment 11•26 years ago
|
||
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
Comment 12•26 years ago
|
||
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]".
Updated•26 years ago
|
Assignee: beard → kmcclusk
Status: REOPENED → NEW
Comment 13•26 years ago
|
||
This bug seems more layout oriented than compositor, or I suppose GFX image
handling.
Comment 14•26 years ago
|
||
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.
Reporter | ||
Updated•26 years ago
|
Component: Compositor → Layout
Reporter | ||
Comment 15•26 years ago
|
||
Ian's wish is my command...reassigning to layout...
Updated•26 years ago
|
Assignee: kmcclusk → rickg
Comment 16•26 years ago
|
||
Rick I am reassigning to you since it is a layout issue, not a gfx or compositor
issue.
Comment 17•26 years ago
|
||
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
Updated•26 years ago
|
Summary: Image name displayed as ALT text when image can't be loaded → Algorithm for finding alternate text for broken images
Target Milestone: M15
Comment 18•26 years ago
|
||
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
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Target Milestone: M15
Comment 19•26 years ago
|
||
Ok. Verifying.
Comment 20•25 years ago
|
||
*** Bug 16623 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•