bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

ALT text truncated by image outline bounds

VERIFIED INVALID

Status

()

Core
Layout
P3
minor
VERIFIED INVALID
19 years ago
19 years ago

People

(Reporter: Crysgem, Assigned: troy)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE] two images with ALT tags, the second image points to an invalid location., URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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

19 years ago
[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

19 years ago
elig@netscape.com:

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.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 4

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
Summary: ALT text larger than bounds which contain it → ALT text truncated by image outline bounds

Comment 5

19 years ago
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

19 years ago
Created attachment 884 [details]
ALT text truncated in upper-left of display
(Reporter)

Updated

19 years ago

Comment 7

19 years ago
The document at the URL now cited exhibits other problems, but I am loathe to
report HTMLTable bugs... the eyes of py8ieh=bugzilla@bath.ac.uk and
elig@netscape.com are surely sufficient to identify any new bugs, if any are
demonstrated at the page. [Nullifying Invalid resolution]

Updated

19 years ago
Assignee: rickg → kipp
Status: REOPENED → NEW

Comment 8

19 years ago
Layout error.
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).

Updated

19 years ago
Whiteboard: [TESTCASE] two images with ALT tags, the second image points to an invalid location.

Comment 10

19 years ago
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

19 years ago
Created attachment 1081 [details]
Testcase - two images with ALT tags, one image SRC is a valid URL the other is invalid.

Updated

19 years ago
Assignee: kipp → troy
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 12

19 years ago
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

Updated

19 years ago
QA Contact: elig → py8ieh=bugzilla

Comment 13

19 years ago
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!
Status: RESOLVED → VERIFIED
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...
You need to log in before you can comment on or make changes to this bug.