Closed Bug 1994 Opened 21 years ago Closed 20 years ago

IMG alt text should go inline when image cannot be displayed

Categories

(Core :: Layout, defect, P2)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ian, Assigned: rods)

References

()

Details

(Keywords: regression, testcase, Whiteboard: see bug 75185)

Attachments

(2 files)

The alt text of an IMG element is alternative text, that is,
text that should completely replace the image, if the image
cannot be shown. In other words, if the image could not be
drawn, then it should not be replaced by a box containing
the alt text, instead, the alt text should be drawn inline.

The quoted uri has more on this, including some tests.

Lynx does this correctly.

(Note: I really don't know which Component this applies
to. Layout? Content Model? Rendering? Viewer App?)
Assignee: kipp → troy
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → LATER
Why not fix this in version 5? This is actually an important issue, even if
it does require some thought before implementation.

Come on! Be the first graphical browser to do this right!!!

(BTW, the page moved. Uri was corrected.)
Status: RESOLVED → REOPENED
I agree with you that the behavior you describe is the correct bahavior. The two
reasons why this probably won't get done for 5.0 are:
- time. It takes time to redo the way this works
- backwards compatibility. Even though you're right and we're doing it wrong,
we've always done it wrong. To change it will "break" a number of pages out
there

We are planning on properly implementing this for the OBJECT tag, which means
you could use the OBJECT instead of the IMG tag and get what you want.

I'll mark it REMIND instead of LATER, and see if we can do it if we have time.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: LATER → REMIND
That sounds fair to me. :-)

RE the backwards compatability issue: couldn't this be one of those
DOCTYPE-based decisions? (e.g., CSS inheritence-into-tables is,
IIRC, switched to "compatability" mode depending on the DOCTYPE
of the document.)
Status: RESOLVED → REOPENED
Status: REOPENED → ASSIGNED
Setting all current Open/Normal to M4.
Resolution: REMIND → ---
Status: ASSIGNED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → REMIND
In the case of an inline image, it makes sense that the alternate text would be
displayed inline, of course.

However, if using CSS the image is specified to be block-level, floated, or
absolutely positioned, then I don't think it makes sense for the alternate text
to be displayed inline. In that case it makes the most sense to display the
alternate text as block-level, floated, or absolutely positioned.

This is one of those areas where the HTML4 spec isn't of much help, because it
only discusses inloine-level images. Cc'ing David Baron for his insight as well
Status: RESOLVED → REOPENED
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: REMIND → FIXED
Okay, this is now enabled on all platforms (tested on Windows and Unix). We'll
now display the alternate content (no border or broken icon) if the image can
not be rendered.

We display the alternate content in the same fashion as the image was displayed.
That means if the image was floated or positioned, then the alternate content is
floated or positioned.

That seems the most sensinble, at least until CSS provides a way to specify
different style info for the image when it's replaced versus regular
I agree about the positioning.  Treat ALT of an IMG as if it were the content
of an OBJECT, and if the image exists, then the ALT is replaced by the image
(and the IMG element is a replaced element).

I think that's what you're now doing.
Yes, that's what I'm doing. Thanks for the clarification
Yup, I agree with the above. I haven't tested it yet, but expect to do so in the
next few days.
*** Bug 6166 has been marked as a duplicate of this bug. ***
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]".
*** Bug 3268 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Target Milestone: M4 → M15
Assignee: troy → kipp
Status: REOPENED → NEW
Whiteboard: Regressed
This has regressed.
Resolution: FIXED → ---
Assignee: kipp → troy
Blocks: 5764
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
I just turned this feature back on.
Status: RESOLVED → REOPENED
Whiteboard: Regressed → [TESTCASE]
Target Milestone: M15
I'm reopening this bug because we still have a plethora of problems with alt
texts on broken images.

There is a comprehensive test page for this here:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html
We currently fail more than 50% of the test lines.

To be precise, the problems are:
 * Images with alt="" are not using the empty alt text.
 * Broken <input type=image> elements still get placeholders.
 * The <input type=image> element's "name" attribute is ignored.
 * Images that are links are unclickable.
 * Images that are still downloading but have no explicit width=/height=
   are being given placeholders (which is pointless).
 * The :first-letter pseudo-element is not applied to alt text.
Blocks: html4.01
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Ian, I'm really starting to regret I let you talk me into implementing this
feature.
Ian, please open a new bug for the problem of <input type=image>, I'll give that
bug to Eric.
Blocks: 8979
The <input type=image> issue is now covered by bug 8979.
Thanks
Depends on: 5349
To address the remaining concerns one by one:
 * Images with alt="" are not using the empty alt text.
THIS WILL BE FIXED AT SOME POINT. TODAY I CAN'T TELL WHETHER THE ATTRIBUTE IS
EMPTY TEXT OR NOT SPECIFIED AT ALL

 * Images that are links are unclickable.
THIS IS BUG #5349 (I'M ADDING IT TO THE DEPENDS LIST ABOVE)

 * Images that are still downloading but have no explicit width=/height=
   are being given placeholders (which is pointless).
THAT WAS A RECENT CHANGE TO FORCE A MINIMUM SIZE FOR THE FRAME FOR LOADING
IMAGES. I DON'T REALLY LIKE THIS, BUT IT'S MORE BACKWARDS COMPATIBLE, AND IT
DOES OFFER THE ADVANTAGE OF PROVIDING THE USER FEEDBACK THAT WE'RE STILL LOADING
IMAGES. THE DOWNSIDE IS THAT IT TAKES UP EXTRA SPACE AND MAY ALTER THE DOCUMENT
APPEARANCE.

 * The :first-letter pseudo-element is not applied to alt text.
THAT'S FOR KIPP TO FIX AT SOME POINT.
Target Milestone: M10
Depends on: 6052
The problem I mentioned about now being able to tell whether the attribute value
is an empty string vs. not specified at all is when using the DOM image
interface. The bug number is 6052, which I'm adding to the depends list above
Regarding images that are still downloading but have no explicit width=/height=
being given placeholders, note that the current system means that the page
will almost certainly have to be reflowed, and in the meantime, the page can
be difficult to read (frames all over the place). If instead we assume that
images without dimensions will fail until proven otherwise, then if the image is
broken, a reflow will not be needed, and if the image is ok, then the reader
will be pleased that the page has suddenly improved.

Also, feedback is already being given by our "remaining items to download"
status line and the throbber. The page itself doesn't really need to worry
about that, IMHO.

Not that it matters much to me - I don't think the pre-download behaviour is
specified by the specs.

[About the alt="" vs no alt problem: you may wish to investigate how the CSS
code figures out an attribute is present or not, since that seems to work ok.
It probably uses a totally different interface, but it may be worth a look...]
Depends on: 10767
Target Milestone: M10 → M11
As agreed with Beth, assigning myself as QA contact for all 'alt text' bugs...
Depends on: 5886
No longer depends on: 5349
Target Milestone: M11 → M13
Blocks: 15545
*** Bug 16619 has been marked as a duplicate of this bug. ***
Blocks: 8131
The M10 build replaces a broken image without ALT text, with the filename
(minus the extension) of the image. I think that's going a bit too far. Don't
you?

I mean this whole inline alt text will mess up a lot of pages, but I guess it's
tolerable since it's 'spec.' But then it's a bit much, IMHO, to go ahead and
start putting file names as inline alt text.
That's what the spec says. The filename is only used as a last resort
Yup - if you want the image to not display any alternate text, e.g. for
decorative images, then you should set alt="". This is currently broken but that
is blocked on bug 6052, which is blocked on bug 1663.

BTW -- not giving the alt text is invalid in HTML4. If pages don't give the alt
text then they will already be "breaking" many pages in browsers that already do
the right thing, e.g. Lynx and voice browsers.
You're right there with that point.

But I'm also concerned about the layout aspect of things. What about the width
and height of broken images? If you know the width and/or height, can you at
least make that much space on the page (without the image frame)? Or in the
case of a image that's part of the link, the bounding box would be that size
(if the border attribute is more than 0, or missing).

Not using this data could break a lot of pages (of course these pages would
already be broken, because of missing images :(  ,but nevertheless).

I also couldn't get apprunner to leave the images out. When they are left out
the above point make more sense.

In other words not using the width and height when leaving images out (either
by necessity in the case of broken links, or by the users choice) would junk
out the layout of a page. Of course you're not supposed to use use images for
layout according to the spec, but that's been done so much already on the web,
and these pages (with images turned off) would look terrible.
If the images are { display: block } then their dimensions are used.

Anyway, that the "layout aspect of things" is also already messing up Lynx and
voice browsers in the cases where the pages are badly designed. This is just
another case where this feature will actually force authors to write more
accessible pages.
Depends on: 18779
*** Bug 18491 has been marked as a duplicate of this bug. ***
Much to everyone's surprise I'm working on fixing this. Vidir finally admitted
he's not going to fix the DOM APIs, and so I'm directly getting the attribute
values using the nsIContent::GetAttribute() function

One question. What if the user does this: 'IMG alt title="title" src=...', i.e.,
there is an ALT attribute specified but it has no value.

Is that the same as alt="" or should we use the value of the TITLE attribute
instead?
Woohoo! :-)

   <IMG alt title="title" src=...>

It's invalid. I'd say treat it as alt="", since 'alt' is specified but has no
value, which is pretty much what alt="" means.
Good. That's what I am doing.

As soon as the tree opens again I'll check the changes in
Target Milestone: M13 → M15
For the <object> element equivalent of this bug, see bug 797, bug 15019, bug
22047, and bug 678.
s/bug 22047/bug 22037/

Ah, the miracle of cut and paste. A great proponent of the main feature of
computers: allowing users to make more mistakes, quicker than ever before. :-/
Status: ASSIGNED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
I changed it so that we now look for the attribute value being the "" (empty
string) and in that case we set the alternate content to "" instead of trying
the next attribute

That's what was left to fix in this bug report. If you see that image buttons
(or something else isn't working), then create a new bug please
Depends on: 23691
Status: RESOLVED → VERIFIED
No longer depends on: 23691
Marking verified. Woohoo!

Remaining bugs are covered by:
   bug 8979 - <input type="image"> issues
   bug 15545 - Broken floating IMG elements dissapear
   bug 23691 - Inline IMGs without a size should not have a placeholder box
Blocks: 23691
Blocks: 24125
Blocks: 24126
No longer depends on: 18779
Blocks: 24815
Blocks: 26282
No longer depends on: 10767
Blocks: 24778
Blocks: 31451
Reopening.
IMG alt does no longer go inline using 2000042215 nightly on Windows 2000.
Status: VERIFIED → REOPENED
Keywords: regression
Resolution: FIXED → ---
How come this is still M15? M15 is already out!
Changing milestone since M15 is out.
Target Milestone: M15 → M16
mLowSrcImageLoader seems to be always created even if lowsrc attribute is not 
there.
Reassigning to rods since he added the lowsrc stuff.
See bug 27388.
Assignee: troy → rods
Status: REOPENED → NEW
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Thanks for the patch, but I needed add a couple of other additional checks. It's 
fixed.
Attached file Testcases
Verified fixed using 2000050215 nightly build on Windows 2000.
Status: RESOLVED → VERIFIED
Blocks: moz-broken
Blocks: 34981
Blocks: metadata
No longer blocks: metadata
bug 1994 has now become bug 75185. Removing dependencies from this bug to
clear the confusion.
No longer depends on: 5886, 6052
Keywords: testcase
Whiteboard: [TESTCASE] → see bug 75185
You need to log in before you can comment on or make changes to this bug.