1994 - IMG alt text should go inline when image cannot be displayed

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Hixie (not reading bugmail)]

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?)

Comment 1

[Hixie (not reading bugmail)]

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.)

Comment 2

[troy]

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.

Comment 3

[Hixie (not reading bugmail)]

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.)

Comment 4

[leger]

Setting all current Open/Normal to M4.

Comment 5

[troy]

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

Comment 6

[troy]

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

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 8

[troy]

Yes, that's what I'm doing. Thanks for the clarification

Comment 9

[Hixie (not reading bugmail)]

Yup, I agree with the above. I haven't tested it yet, but expect to do so in the
next few days.

Comment 10

[rickg]

*** Bug 6166 has been marked as a duplicate of this bug. ***

Comment 11

[Hixie (not reading bugmail)]

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]".

Comment 12

[Hixie (not reading bugmail)]

*** Bug 3268 has been marked as a duplicate of this bug. ***

Comment 13

[Hixie (not reading bugmail)]

This has regressed.

Comment 14

[troy]

I just turned this feature back on.

Comment 15

[Hixie (not reading bugmail)]

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.

Comment 16

[troy]

Ian, I'm really starting to regret I let you talk me into implementing this
feature.

Comment 17

[troy]

Ian, please open a new bug for the problem of <input type=image>, I'll give that
bug to Eric.

Comment 18

[Hixie (not reading bugmail)]

The <input type=image> issue is now covered by bug 8979.

Comment 19

[troy]

Thanks

Comment 20

[troy]

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.

Comment 21

[troy]

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

Comment 22

[Hixie (not reading bugmail)]

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...]

Comment 23

[Hixie (not reading bugmail)]

As agreed with Beth, assigning myself as QA contact for all 'alt text' bugs...

Comment 24

[Masatoshi Kimura [:emk]]

*** Bug 16619 has been marked as a duplicate of this bug. ***

Comment 25

[Daryl Lee]

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.

Comment 26

[troy]

That's what the spec says. The filename is only used as a last resort

Comment 27

[Hixie (not reading bugmail)]

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.

Comment 28

[Daryl Lee]

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.

Comment 29

[Hixie (not reading bugmail)]

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.

Comment 30

[Nisheeth Ranjan]

*** Bug 18491 has been marked as a duplicate of this bug. ***

Comment 31

[troy]

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?

Comment 32

[Hixie (not reading bugmail)]

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.

Comment 33

[troy]

Good. That's what I am doing.

As soon as the tree opens again I'll check the changes in

Comment 34

[Hixie (not reading bugmail)]

For the <object> element equivalent of this bug, see bug 797, bug 15019, bug
22047, and bug 678.

Comment 35

[Hixie (not reading bugmail)]

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. :-/

Comment 36

[troy]

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

Comment 37

[Hixie (not reading bugmail)]

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

Comment 38

[Masatoshi Kimura [:emk]]

Reopening.
IMG alt does no longer go inline using 2000042215 nightly on Windows 2000.

Comment 39

[moshev]

How come this is still M15? M15 is already out!

Comment 40

[Masatoshi Kimura [:emk]]

Changing milestone since M15 is out.

Comment 41

[Masatoshi Kimura [:emk]]

mLowSrcImageLoader seems to be always created even if lowsrc attribute is not 
there.

Comment 42

[Masatoshi Kimura [:emk]]

Attachment: Proposed patch: changing lowsrc existence check. This will solve the problem

Comment 43

[Masatoshi Kimura [:emk]]

Reassigning to rods since he added the lowsrc stuff.
See bug 27388.

Comment 44

[rods (gone)]

Thanks for the patch, but I needed add a couple of other additional checks. It's 
fixed.

Comment 45

[rods (gone)]

Attachment: Testcases

Comment 46

[Masatoshi Kimura [:emk]]

Verified fixed using 2000050215 nightly build on Windows 2000.

Comment 47

[Hixie (not reading bugmail)]

bug 1994 has now become bug 75185. Removing dependencies from this bug to
clear the confusion.