109410 - Visually expand ALT text in placeholders to full length so it can be read

Status: RESOLVED DUPLICATE of bug 149157

(SeaMonkey :: UI Design, defect)

Description

[Skewer]

Currently, there is no way to read ALT text while an image is loading if it
exceeds the size of the image placeholder, nor after the picture is loaded. It
would be a good idea to display the ALT text as a tooltip, so the entire text
can be read at any time. If a TITLE is provided that will be displayed instead.

Build: 2001110903 W98

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

This has been proposed already, and marked wontfix.

If an image is loading, the alt text should not be displayed.  ALT text is
supposed to be displayed ONLY when the image is not available.  If a tooltip is
wanted, it should be in the title attribute.  Period.  Let's advocate title
instead of providing a lazy workaround which hinders accessibility rather than
helps it.

*** This bug has been marked as a duplicate of 88297 ***

Comment 2

[sairuh (rarely reading bugmail)]

v

Comment 3

[Skewer]

Reopening and changing summary. You misunderstood the point of this bug.

The idea is to make ALT text readable when the image does not load for whatever 
reason (or loads slowly). Obviously this isn't an evangelism or standards 
compliance issue because web developers can't anticipate this situation. Right 
now it's impossible to read the ALT text of an image while it is loading 
because the placeholder is too small. If the image is broken, right now the ALT 
text ends up being displayed as normal text; but this behavior needs to change 
(and there is a bug filed on it somewhere). This will prevent situations where 
a user cannot read the ALT text when the image is not displayed. When the image 
is displayed correctly, it would be nice (and much easier) to leave that ALT 
text in the tooltip, but if it's that big of an issue we can get rid of the 
tooltip once the image loads.

Before it loads (if at all), we have serious usability issues that have nothing 
to do with W3C correctness or evangelism.

As an example, in much of Windows, if text exceeds the size of its container, a 
tooltip will appear showing both the visible and obscured parts of the text. 
Try this on almost anything that is cropped and has "..." on it.

Comment 4

[Skewer]

And actually, I was wrong before. If an image doesn't load we should expand 
that ALT text whether or not there is a TITLE. In other words, we should draw 
either one tooltip with both the expanded ALT text and the TITLE text inside, 
or draw two tooltips, one for each (without overlapping them, of course).

Comment 5

[Christopher Hoess (gone)]

This is a quite natural result of the broken behavior introducted by bug 102281.
 Let's see what comes of that before we do anything about this; after all, the
assumption promulgated by the new quirks-mode behavior is that it is the size of
images and their position in the layout that is important, which is generally
mutually exclusive with meaningful alt text.

Comment 6

[Hixie (not reading bugmail)]

As Chris and Chris have said, this _is_ a duplicate of bug 88297 and would be a
non-issue if it wasn't for bug 102281.

Comment 7

[Skewer]

Ian: That bug is *not* the same as this one. That bug is a feature request to
display ALT text as a tooltip when there is no title, created before we changed
the way ALT text is displayed. There was little benefit to making the change
requested in bug 88297, but this change is a major improvement in the usability
of alternate text while satisfying the changes made in bug 102281.

Please stop slowing down these bugs with your radical ALT text beliefs. Whether
you like it or not, we've changed the display behavior of image placeholders and
we need a way to expand that ALT text. To suggest that we try to use what little
bit of the ALT text is visible in the placeholder without expanding it is
ridiculous.

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

1. Please do *NOT* remove people's whiteboard markings - it is rude.

2. Do *NOT* re-assign bugs without reason.  It appears you reassigned this
solely due to the fact you don't like the views of who it is assigned to.  Again
bad etiquette.

3. The "radical" ALT beliefs are actually the standard.  And instead of
criticising one's beliefs and making baseless accusations, why not focus on
pointing out the merits of your argument?  This is an organized bug database,
not a political mudslinging forum.  You are going to have a better time of
winning arguments if you don't attack others.

4. This *is* a dupe of 102281.  For a tooltip to be displayed, it must go thru
ChromeTooltipListener.  Currently it ignores ALT attributes.  Bug 88297 requests
to return the ALT attribute text if there is no TITLE attribute.  You are
requesting us to display ALT text as a tooltip if there is no TITLE attribute
(special case, but in your special case, you cannot deny that is what you are
asking).  Explain to me again how that is not a dupe.

5. I don't know about you, but I personally, and many people I work with surf
quite a few sites which load slowly as we are on a split T1 line at work, our
total bandwidth for the whole building is limited to 256kbps, and I can honestly
say that whenever I or anyone else loading a slow page sees an image
placeholder, I've not once EVER seen anyone say "Oh, the image hasn't loaded
yet, I think I will hover over the image to see if it has a tooltip."  It's just
something that people don't do.  Either I wait for the site to load, or I
ALT+TAB to another window to do something else.  You are assuming that users are
patient enough to sit there and mouseover tooltips on broken sites.  Like it or
not, people like graphics better than text.  Hovering over an image is work. 
People are lazy.  They would rather just sit there and wait or do something else
to not waste time than to mouseover image placeholders aimlessly.  Can you
provide an estimate as to how many users this would benefit?  Would it be worth
breaking our standards compliance for?  I highly doubt it.

Comment 9

[Skewer]

Related:

Bug 110213: Draw appropriately sized placeholder regardless of standard/quirks mode

This bug blocks compatibility with W3C's user agent accessibility guidelines
<http://www.w3.org/TR/UAAG10/>. That document states that we should "allow the
user to designate a placeholder and request to view the associated content in a
separate viewport (e.g., through the context menu), leaving the placeholder in
context." That sounds like a perfect situation in which to use a tooltip.

Comment 10

[Skewer]

> 1. Please do *NOT* remove people's whiteboard markings - it is rude.
>
> 2. Do *NOT* re-assign bugs without reason.  It appears you reassigned this
> solely due to the fact you don't like the views of who it is assigned to.
> Again bad etiquette.

Your assessment of this bug is incorrect. Under the circumstances, you calling
my actions rude is like a pot calling the kettle black. You can't reassign bugs
just because you personally think they're stupid. You clearly only took this bug
because you wanted to kill it. Do you have something against the progress of
Mozilla?

> 3. The "radical" ALT beliefs are actually the standard.  And instead of
> criticising one's beliefs and making baseless accusations, why not focus on
> pointing out the merits of your argument?  This is an organized bug database,
> not a political mudslinging forum.  You are going to have a better time of
> winning arguments if you don't attack others.

What standard? The "Because Ian Said So" standard you cite in bug 41924? No one
person can create a standard; a standard must be something for which there is a
general agreement, and from all the Bugzilla comments it should be clear that
this is not the case. Meanwhile I just posted a reference to a W3C
recommendation that supports the expansion of ALT text. Besides the standards,
it just makes sense to expand ALT text--it would be absolutely ridiculous to
just leave it in its placeholder with no way to read anything beyond the first
few words.

> 4. This *is* a dupe of 102281.  For a tooltip to be displayed, it must go thru
> ChromeTooltipListener.  Currently it ignores ALT attributes.  Bug 88297
> requests to return the ALT attribute text if there is no TITLE attribute.
> You are requesting us to display ALT text as a tooltip if there is no TITLE
> attribute (special case, but in your special case, you cannot deny that is
> what you are asking).  Explain to me again how that is not a dupe.

The intentions are different. The fix may not be, and if that's enough reason to
dupe this bug to a bug which is already bloated with useless arguing we can make
this a dupe and reopen that bug. That would make no sense and just obfuscate the
procedure to fixing this bug (and calling it a WONTFIX is just not acceptable in
the interest of meeting W3C standards).

...
> whenever I or anyone else loading a slow page sees an image
> placeholder, I've not once EVER seen anyone say "Oh, the image hasn't loaded
> yet, I think I will hover over the image to see if it has a tooltip."
> It's just something that people don't do.  Either I wait for the site to load

Sometimes the images don't load, though. At all. In perpetuity throughout the
universe.

> Can you provide an estimate as to how many users this would benefit?

It's worth it if fixing this bug only benefits a few users. However, I'm sure
the benefits are greater than you might expect.

> Would it be worth breaking our standards compliance for?

Actually, this is a matter of *improving* standards compliance, not *breaking*
it. Do you think W3C would be happy about the way we handle ALT text currently
(trimming it without a means of expansion)?

Comment 11

[Skewer]

Adding CC for previous owner, even though this bug *will* ultimately have to be
reassigned to someone who plans to fix it.

Comment 12

[Skewer]

> Your assessment of this bug is incorrect. Under the circumstances, you calling
> my actions rude is like a pot calling the kettle black. You can't reassign bugs
> just because you personally think they're stupid. You clearly only took this bug
> because you wanted to kill it. Do you have something against the progress of
> Mozilla?

Er, change "you" to "Ian." I never expected anyone other than him to argue for
that reassignment.

Comment 13

[Christopher Hoess (gone)]

Skewer, would you please try reading the specs for meaning before you claim that
broken behavior is mandated by the spec?  Here's some free clues for you: of the
five people cc'd to this bug at present, one is a member of a standards body, or
reasonable facsimile thereof.  I'll let you guess who that is.  Next clue: the
first FAQ I could find about alt text on the web enthusiastically recommends
Hixie's spec.  Some further surfing in Google results reveals that this FAQ
seems to be fairly well accepted, as it's reprinted on htmlhelp.com and linked
to by several other discussions of alt text.  Oh no, it's a conspiracy!

I tell you what, though: find me a member of one of the accessibility working
groups (discovering their email addresses and appropriate mailing lists for
asking such questions is left as a trivial exercise for the reader) who will say
"When an image cannot be loaded, the response should be to create a box the size
of that image, draw the alt text in it, and provide a means of accessing the alt
content that has been cut off, rather than displaying alt text inline." 
[n.b.-for my purposes here, displaying inline does not preclude outlining or
special highlighting to display that the text in question is alt text, which I
believe Opera does, and which I think we should adopt now that I've found out
about it :-)  Presence or absence in the inline flow is what I'm concerned with
here.]  You do this, and I'll withdraw all objection to this proposal AND
apologize to you publically, in both bugzilla and newsgroups.  After all, this
is backed up by the spec, right?  And the accessibility people are here to make
browsers do the right thing, right?  And they should be only too glad to help
correct wrong-headed implementors like Hixie and me, right?  Go for it, big guy.
 We'll be watching your career with interest.

Advanced Assignment: I agree 100% that the complete alt text should be shown
when images are turned off.  There is a method of implementing this that has not
yet been discussed either here nor in bug 102281.  Discover it.  You will not
like it.

Comment 14

[Hixie (not reading bugmail)]

Note: The reason I reassigned this bug was to save pchen from the massive
spammage that I (rightly) guessed would ensue.

Comment 15

[Skewer]

The thing is, we're already doing most of this stuff. We're already drawing
images in boxes at the specified dimensions in quirks (and should be in standard
mode as well). There is nothing you can say or do to change that--the fix is
checked in, Netscape likes it, forget about it. Now that it's going to behave
this way, we need to fix the way ALT text is displayed. If you're disagreeing
with me, what you're basically saying is this: "We should hide all the ALT text
from the user that he doesn't already see in the placeholder." Hiding ALT text
definitely *does* break standard compliance.

Comment 16

[Christopher Hoess (gone)]

Skewer: Please read for comprehension.  I said I agreed 100% that the whole alt
text needs to be displayed.  I don't support your aesthetic atrocity of double
tooltips (which would, I think, be considerably harder to implement than you
realize-and hyatt has enough on his plate for 1.0 already.)  Deduce from this
what you will.

May I take it that you don't feel your interpretation of the specification will
be that supported by those who wrote it?  They don't have to reply personally or
in bugzila or anything, a quote from an accessibility WG member on a W3C mailing
list will work fine.

You do understand this idea of "burden of proof," right, given that the use of
line boxes is contrary to the opinion of evil, elitist standards geeks like
Hixie and myself AND every FAQ or authoring article on alt text that discussed
the issue?

You are familiar with the term "straw man", which is the type of argument you
used in your last post, right?

I'll leave you to ponder that.  Oh, and when I say "free clue", I mean it.  I
may not suffer fools gladly, but I do try to give them a hand as I do it.

removing poor pchen, who doesn't need to be assailed with all this.

Comment 17

[Skewer]

If you want to talk logical fallacies, I'll be glad to oblige. Your entire
argument (the collective you includes Ian, Aillon, and Hoess) completely lacks
any basis (it is emotive language, although there are better words for such
nonsense). I have shown a W3C document that supports this change. It's
ridiculous to say that I should have to contact someone at W3C and ask them if
it's okay to do something which is *already standardized*. Meanwhile all of you
make it your goal to turn these valid bugs into Bugzilla trash because of your
convenient "can modify any bug" priviliges. And yet the whole time, not once has
any of you cited a standard which states or even implies that it would be better
to leave things the way they are now than to change them. I'm interested in
anything you can show me to suggest that our behavior goes against a W3C
standard--and you're the ones who haven't provided any evidence, so you should
be the ones who go out on a limb e-mailing members of W3C lists. It's not enough
to just set WONTFIX to make a bug go away, you need to at least give some reason
why it's better the way we're doing it now.

Current behavior: Can only read a little of the ALT text in a small placeholder.
Expected behavior: Can read all of the ALT text.

Comment 18

[Christopher Hoess (gone)]

I have had your argument somewhat confused with that of other people in bug
108221.  While I feel that the behavior implemented there for quirks mode is
sub-optimal, that appears to be a dead issue for the time being; I think the
best way to implement "boxes", if we will do them, is in the same way as IE, so
that they auto-expand.

I think we may, in fact, agree on this.

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

Skewer, if you want to talk fallacies, your whole argument is based upon an
interpretation of a standard.  Not all interpretations of standards are correct.
 If they were, then MSIE would be arguably the most standards compliant browser
available.

Now since you are obviously avoiding doing the necessary research, and obviously
trying to make the research more difficult for us (you quoted something from the
user agent accessibility guidelines glossary, but linked to the document as a
whole instead of directly to the glossary), I will oblige.   I am even going to
play devil's advocate and take your side of this.

http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content
* If C is a summary, title, alternative, description, or expansion of another
piece of content D, provide access through at least one of the following mechanisms:
    * (1a) render C in place of D;
    * (2a) render C in addition to D;
    * (3a) provide access to C by querying D. In this case, the user agent must
also alert the user, on a per-element basis, to the existence of C (so that the
user knows to query D);
    * (4a) allow the user to follow a link to C from the context of D.

In the above, please realize that for the purpose of this bug, C denotes the alt
attribute of an image element, whereas D denotes the image element.  Since I
said I am going to take your side, I will give you the fact that displaying a
tooltip for the alt attribute is rendering C (alt) in addition to D (img),
thereby fulfilling 2a.

Rebuttal [c'mon you knew this was coming didn't you? ;-) ]

The part where this fails, though is simple: what happens when there *is* a
title in addition to an alt attribute?  I am pretty sure that you do not dispute
we should display the title as a tooltip in this instance, It was made clear
that you are aware that title is displayed as a tooltip and you respect it since
your intial bug report summary included "when there is no TITLE".  So if we
render the title attribute as a tooltip, whoops! Now the ALT attribute is not
rendered.  In addition, the user is confused as to what attribute we are
displaying.  Is this the title or alternative text?  It is confusing to site
authors who are unsure of what will be rendered - should they code title or alt?
 And THAT is a bad thing.  Because then we have site authors who start coding
<img alt="Click here for foo" title="Click here for foo"/> which I think we can
all agree is BAD for accessibility. 

We already have an attribute we display as a tooltip, title be thy name.

However, I do agree with you on the fact that we should use one of the four
methods outlined.  I'm wondering if the 'Properties' dialog would be a better
place for having ALT text displayed...

I'm going to again WONTFIX this because of the reasons outlined above why we
should not use tooltips for expanding ALT text (which is what *this* specific
bug is about).

Comment 20

[Skewer]

The arguments are here; we don't need to start another bug (and if one exists or
does get created, dup this to it). This is still *not* a WONTFIX, provided you
make the necessary changes to the summary (done now). Please read
<http://bugzilla.mozilla.org/bug_status.html> and learn how to use resolutions
properly, since it doesn't appear that you understand this yet.

Comment 21

[Scott Tran (Wildcard)]

Resolving->DUPE of 110213
The summary nowhere matches whats being discussed in this bug
Skewer I suggest you stop changing the Summary around on your bugs... It causes
them to be way too confusing to follow


*** This bug has been marked as a duplicate of 110213 ***

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

For the record:

1: The last checkin to bug_status.html was a patch by one of the people CC'd on
this bug.  Figure out who.

2: Two of the people on this bug are active developers of Bugzilla.  Figure out who.

3: If anyone needs to learn how to work with bugs, it would be the person who
thinks that just because you re-summarize a bug, it is now OK to re-open it. 
Why don't you re-summarize every Resolved/Verified/Closed bug in the database? 
I'm sure you could think of ways to re-open each and every one of them.  Your
creativity astounds me.

4: This bug could really be just as easily resolved INVALID now.  The original
bug had nothing to do with placeholders.  You wanted it as a tooltip, and this
is the THIRD time you have re-summarized the bug just for the fact of reopening
it.  Bugs get resolved sometimes.  Deal with it.  PS. I done learn't that on the
page you ref'renced me to.

5: Contrary to what someone may believe, I hold no grudges against anyone on
this bug.  I am merely frustrated that one bug has taken on the form of three
and refused to die when it has been made obvious that it should do so.  This is
a bug database, not the Harry Potter movie.  No magical transformations please.

6: I am verifying this bug.

*7: !!!! Please do not re-open this bug !!!!*  I am sure the people CC'd on bug
102281 would greatly appreciate it.

Comment 23

[Skewer]

Reopening...

Comment 24

[Skewer]

Dup of bug 149157 (ALT text is cropped in quirks mode)

*** This bug has been marked as a duplicate of 149157 ***