149157 - ALT text is cropped in quirks mode

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Skewer]

This was broken off of bug 41924. Several other bugs were closed due to 
confusion, I'll keep this simple.

Currently a bug exists in quirks mode where an image's ALT text is placed 
inside a box and is only partially readable. ALT text should never be cut short 
like that. My proposed solution is to make the full ALT text available to the 
user.

------- Additional Comment #109 From Skewer (Not reading mail) 2001-12-19 
22:01 -------

Attachment 62318 [details] is an example of the behavior I was trying to describe in bug
109410. Do not confuse the expanded ALT text for a tooltip--it will only be
displayed when the ALT text is clipped and not when the image properly loads.
The TITLE is displayed as a tooltip. We might first expand the ALT text, then
display the TITLE in a tooltip. They should both be displayed at the same time,
despite the way it is rendered in the demo.

---

Do NOT dup this without showing me the bug you plan to dup it to beforehand. 
Chances are I already know about the bugs you're thinking of duping this to and 
they are NOT duplicates.

Comment 1

[Skewer]

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

Comment 2

[Hixie (not reading bugmail)]

In quirks mode, our priority is to layout, not to faithful rendering of the alt
text. If we were faithful, we wouldn't be rendering the alt text in a box, we'd
be doing it inline, like we do in standard mode.

-> WONTFIX, unless you can propose a solution that does not involve mouseover
effects (too easily confused with tooltips, and we do not want to confuse anyone
into thinking that we are implementing alt attributes as tooltips) and does not
involve changing the size of the box (since that would break the layout which we
are working so hard to preserve in the first place).

Note that we will be giving users control over the placeholder box once we have
fixed bug 11011.

Comment 3

[Skewer]

You are being very unreasonable. This is now in direct contradiction to the
whole principle of ALT text and I am suspicious that you have an agenda to
WONTFIX all of my proposals unilaterally. If this irrational behavior is
supposed to get you some kind of trophy, you've certainly done your part to
impress the award givers.

Even if a tooltip is not a good solution, cropped ALT text is still a problem.
You cannot say that this is a WONTFIX unless you plan for Mozilla to be a
browser that neglects standards. This is a valid problem, and if I have to
reopen it every damn time you WONTFIX it I will.

I have already stated before that this will *not* behave like a tooltip, since
it won't be accessible to the end user unless the placeholder is displayed. The
wrong behavior that you want to discourage is for webmasters to hide a message
in the ALT text that the user can discover by mousing over the image, and that
won't happen in this scenario unless the image is broken. If it might somehow
justify the cropping of ALT text to place an uncropped version in the properties
menu, that would be an awkward but standards-compliant solution to the problem.

And don't forget that the whole idea of quirks mode is to tolerate websites
designed for older browsers, and all the older browsers display ALT text as a
tooltip. You can save the proselytizing for standard mode.

I want to hear comments from the component owner, Marc Attinasi, on this
specific issue. I am tired of your contradictory rambling, Ian.

Comment 4

[Hixie (not reading bugmail)]

Actually the module owner is David Baron; Marc is only the default component
owner which is a different matter altogether.

In reply to your specific comments:

> cropped ALT text is still a problem.

Yes, I totally agree. The correct solution is to not put the alt text in the
placeholder box in the first place, like in standard mode.


> You cannot say that this is a WONTFIX unless you plan for Mozilla to be a
> browser that neglects standards.

In quirks mode, we do.


> I have already stated before that this will *not* behave like a tooltip

Well, you can say that, but the fact of the matter is that what you described is
a tooltip. (Technically, a titletip.)


But since you want the module owner to arbitrate, I'll let David decide what to
do with this bug.

Comment 5

[Skewer]

>> You cannot say that this is a WONTFIX unless you plan for Mozilla to be a
>> browser that neglects standards.

> In quirks mode, we do.

No, we give priority to compatibility, but still honor the standards wherever
possible. In theory quirks mode could have ignored all the CSS that Netscape 4
ignored, but you can plainly see that's not the case.

I fail to see how my suggestion of making the full ALT text available in quirks
mode is unreasonable, since the standards agree with me and doing what I've
proposed won't break any pages.

It's foolish of you to have a vendetta against one specific type of display
(tooltips) just because of what they are. I've clearly explained that the old
trick of hiding messages in tooltips will NOT work, so I fail to see how
displaying the full ALT text on a broken image will encourage bad behavior. And
like I said, and you ignored, this only deals with quirks. You might be able to
get away with "lesson-teaching" in standard mode, but not in quirks. Quirks is
there for compatibility, and right now the issue is being compatible with ALT text.

Comment 6

[Skewer]

qawanted: Does anyone have opinions on the best way to make the full ALT text
available to the end user?

Example: Tall, narrow picture of a chestnut tree. The user would currently see
something like this:

[ [] Che]
[    Tre]
[       ]
[       ]
[       ]

The effect is even worse when the user increases the font size.

Since I still have the usual aggressors to worry about, I will again mention
that this is not an invitation to play with the settings on this bug. I don't
care for WONTFIX resolutions or disparaging scribblings in the status
whiteboard. Just tell me what you think should be done to solve this dilemma.

Comment 7

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

I think it would be perfectly reasonable for the ALT text to be displayed in a
tooltip when all of the following conditions are met (they're the conditions
when this problem occurs, right?):
 * the image is broken, still loading, or not going to be loaded
 * we're in quirks mode
 * the alt text doesn't fit in the placeholder.

After all, tooltips are a reasonably standard UI expectation for cut off text in
at least some environments, and such a behavior wouldn't encourage authors (who
are almost always going to have the images fully loaded, thanks to caching, fast
connections, etc.) to use ALT for tooltips.

That proposal would leave some questions of how such information would compete
for priority with other things that trigger a tooltip.  I'd suggest it should
win, at least in the part of the placeholder where the text is.

Does anyone have any other proposals?

Comment 8

[Skewer]

> That proposal would leave some questions of how such information would compete
> for priority with other things that trigger a tooltip.  I'd suggest it should
> win, at least in the part of the placeholder where the text is.

What should happen is the ALT text should be shown as a tooltip for a while
(perhaps in the overlay fashion I described), then eventually disappear and show
the TITLE text, then go back and forth. I don't like tooltips that disappear
before you can finish reading them, but in this case it makes sense to do that.

Comment 9

[Sören 'Chucker' Kuklau (gone)]

Your proposal is not an optimum solution, to say the least. What happens if some
weird DHTML script decides to display some emulated tooltip over an image?
Should Mozilla display that DHTML's box, and below the whole ALT text, and yet
below the whole tooltip?

Comment 10

[Skewer]

In cases like that where the page author has gone to that extreme length to
bastardize his webpage, we'll just kind of have to let the DHTML obscure the ALT
text (and the TITLE would be handled the way I mentioned before). I think that's
a small price to pay to be able to access the ALT text 99% of the time.

We're all still waiting to hear anyone come up with a better way to display ALT
text than a tooltip with the behavior I described.

Comment 11

[Brian 'netdragon' Bober]

What about allow the user to scroll the text somehow in the broken image?

Comment 12

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #11 From Brian "NeTDeMoN" Bober 2002-09-13 01:34
> What about allow the user to scroll the text somehow in the broken image?

Marquee? ;-)

Comment 13

[Max Kanat-Alexander]

I think a small button might do the trick. When you press the button, a tooltop
appears for the _button_. (Or something else especially clever happens.) For
example:

[  [x]Che]
[     Tre]
[        ]
[        ]
[        ]

It wouldn't have to go there, it could go anywhere. It would contain an elipsis
(...) and be just a few pixels wide or high. In addition, it would probably be
some sort of Preference that defaulted to OFF, since it could break some
existing pages.

It's not a perfect solution, just another suggestion.

-M

Comment 14

[Carine Held]

Test Case attached

Comment 15

[Carine Held]

Attachment: Test Case

Comment 16

[Skewer]

Comment on attachment 109484 [details]
Test Case

This test case does not properly demonstrate this bug.

Comment 17

[Skewer]

Attachment: Testcase with broken images having various width/height attributes and long ALT text

Comment 18

[Skewer]

As you can see, this bug only occurs when width/height attributes are set to the
image (works the same whether using transitional HTML or CSS). Mozilla will
break the image up into a line of text otherwise (expected behavior because the
browser has no information to tell it what width/height the image should be
rendered at).

The browser is doing all sorts of strange things with this testcase. Of course,
the ALT text doesn't fit in the placeholder, and currently there is no tooltip
to show the full ALT text. It is possible to read part of the ALT text in the
property window, but in that case the browser choked on the newline in the code
(instead of doing the W3C-required whitespace conversion).

Comment 19

[Carine Held]

Reproduced with 12/16 Trunk build on Win XP.

Comment 20

[Samir Gehani]

adt: nsbeta1-

Comment 21

[Christopher Hoess (gone)]

->Image: Layout (more specific layout component, just Bugzilla housekeeping)

Comment 22

[Scott]

Resize the image placeholder to allow the ALT text to be shown.  If dimensions
are set for the image; width and height; then use a font for the alt text that
will allow it to be seen inside the image placeholder as well.

[cherry tree]

OR

[cherry   ]
[tree     ]
[         ]
[         ]
[         ]

Comment 23

[Skewer]

Scott: What should the browser do with the testcase? That amount of text
couldn't possibly be displayed in a placeholder so small and still be readable.

Comment 24

[Anne (:annevk)]

Suggesting 'overflow'.

Comment 25

[Paul Silaghi, QA [:pauly]]

This seems to be reproducible in nightly 26.0a1 (2013-08-21). Re-add qawanted if you need specific qa help.