8811 - ALT text truncated by image outline bounds

Status: VERIFIED INVALID

(Core :: Layout, defect, P3)

Description

[Crysgem]

True of the M7 Apprunner build. I am aware that a discussion is ongoing of the decision to present ALT text in-line rather than within a box, but this replication of 4.x's behavior should be perfected first.

Comment 1

[Eli Goldberg]

[QA Assigning to self, as this is imaging-related. CC:ing Ian, since I think he
likes this topic. ;]

---

Crysgem: I don't understand the bug report; could you please provide the
necessary information, per the Bug Writing Guidelines:
	- what *happens* when the ALT text overflows the available space
	- what *should* happen, preferably including a specification or precedent
reference for why this behavior should be correct.

Thanks!

Comment 2

[Crysgem]

[e-mail]:

The ALT text is usually of a scale too large to be appropriate for the outline
containing it. The text does not "overflow" past the outline but is instead
truncated at that boundary. It is expected from past browser behavior that the
text would be of a scale equal to the size of the outlined box, that the ALT
text might be equitably presented.

Comment 3

[Hixie (not reading bugmail)]

elig: Thanks for ccing me.           (Magic Radar Marker: This is an [ALT] bug.)

I am marking this bug INVALID as the ALT text should not be put in a boundary
at all, not even for quirks mode. Troy has very recently (as in, in the past
few hours) checked code in that changes alt text behaviour to the correct mode.
Please download the latest build and see if behaviour is satisfactory.

Comment 4

[Eli Goldberg]

Crysgem and Ian --- thanks!

Using this morning's builds (all 3 platforms), a long ALT text string for a
broken image (test case at http://www.prometheus-music.com/gecko/imgaltlong.html)
is displayed inline in its entirety, rather than within the image border.

Thus, Verifying as Invalid.

Comment 5

[Crysgem]

A sufficient period has passed, and the issue I *INTENDED* to address (and
failed to, in this report) has not abated... thus I reopen, and attach a
screen-shot.
Observe the image outline in the upper-left quadrant of the canvas (with the ALT
text, "Tired of typing? Then"). With Enforcer 5.0 and Ancestor 4.6, that text
fits amply within the outline. Argue as Ye My Betters will of the orthodoxy of
ALT text, but this flaw is yet apparent.

Comment 6

[Crysgem]

Attachment: ALT text truncated in upper-left of display

Comment 7

[Crysgem]

The document at the URL now cited exhibits other problems, but I am loathe to
report HTMLTable bugs... the eyes of py8ieh=[e-mail] and
[e-mail] are surely sufficient to identify any new bugs, if any are
demonstrated at the page. [Nullifying Invalid resolution]

Comment 8

[rickg]

Layout error.

Comment 9

[Hixie (not reading bugmail)]

The alt text _is_ wrapping, it is just too big to fit in the placeholder box.
This bug should be really simple to fix - just change the font-size (and
family, maybe) of the alt text in ua.css. I think Peter was doing work on
that a while back.

BTW, probably a better test case for this would be:

   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html

Right at the top there are two images, one of which takes 60 seconds to load.
That image has a "long alt text" but a small placeholder box (50x50).

Comment 10

[David Hallowell]

I'm attaching a simple test case of the problem. Personally I don't see this as
too much of a problem if the tooltips function (i.e. hovering mouse over image
will display the ALT text) that communicator has is going to be implemented in
Mozilla.

I find it more of a problem if the browser ignores the size of the image
specified (the HEIGHT and WIDTH tags) and displays the text of the image
instead. This can result in major layout problems if the length of the text
string is larger than the image.

Testcase tested on Linux (RH 6.0), Win95/98

Comment 11

[David Hallowell]

Attachment: Testcase - two images with ALT tags, one image SRC is a valid URL the other is invalid.

Comment 12

[troy]

Marking as INVALID. We've been over this issue many times, and Gecko is now
(thanks to Ian) doing exactly what the HTML4 spec says we should do which is
display the contents of the IMG element (typically the value of the ALT
attribute) if the image can not be rendered.

As far as width/height attributes go, we respect them for replaced elements
that's why the placeholder size is determined by the width/height values. If we
can't render the image and we display its content instead, then if it's an
inline image it's no longer a replaced element and hence width/height don't
apply

Comment 13

[Eli Goldberg]

Taking the liberty of QA Assigning to Ian for verification, who I suspect has
more of an opinion in the matter than I do. (Ian, if I've guessed incorrectly,
please just QA Assign it back to me to rubber-stamp as verified.)

Thank you!

Comment 14

[Hixie (not reading bugmail)]

This bug is getting overloaded by side issues. I am verifying it and then
opening bug 12770 to cover the minor issue of making the font size in the place
holder box smaller, which I think was the original issue...