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.
*** Bug 109410 has been marked as a duplicate of this bug. ***
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Assignee: attinasi → dbaron
Status: REOPENED → NEW
QA Contact: petersen → ian
>> 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.
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.
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?
> 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.
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?
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.
What about allow the user to scroll the text somehow in the broken image?
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? ;-)
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
Test Case attached
Comment on attachment 109484 [details] Test Case This test case does not properly demonstrate this bug.
Attachment #109484 - Attachment is obsolete: true
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).
Reproduced with 12/16 Trunk build on Win XP.
->Image: Layout (more specific layout component, just Bugzilla housekeeping)
Component: Layout → Image: Layout
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 ] [ ] [ ] [ ]
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.
This seems to be reproducible in nightly 26.0a1 (2013-08-21). Re-add qawanted if you need specific qa help.
You need to log in before you can comment on or make changes to this bug.