Closed Bug 74241 Opened 23 years ago Closed 23 years ago

Have a pref to show image ALT text as tooltip on mouseover

Categories

(Core :: XUL, enhancement)

Product:
Core
Component:
XUL
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: Bugzilla08, Assigned: trudelle)

References

Details

(Whiteboard: [Havecompromise]) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1)
BuildID:    2001033020

When there is no TITLE text or other tooltip to be displayed when moving the
mouse over an inlined image, it would be nice to display the image's ALT text,
if any, just as if it had been included as a TITLE tag.

There is often quite useful information in an image's ALT text that would be
nice to see when moving the mouse over it.  This would also make it behave as
other common browsers (under Windows at least).

If you feel this is too "non-standards" then at least an option in the
preferences to enable this behavior at the user's choice.

Hopefully this shouldn't be much trouble to implement since it is the same
bahavior generated by the TITLE text already.


Reproducible: Always
Steps to Reproduce:
1. Mouse over an image generated by code simular to <IMG SRC="image.gif"
ALT="Image info">


Actual Results:  No tooltip at all is displayed.

Expected Results:  Display tooltip of the ALT parameter.


I'm running under Windows 98 SE.
This discussion has happened already.  See bug 1995 for why we are not planning 
to show alt text in tooltips.  This part of the bug is a duplicate of bug 25537 
and many others....

As for the pref.... I suppose that's a possibility.  Changing summary.
Summary: [RFE] Show image ALT text as tooltip on mouseover → [RFE] Have a pref to show image ALT text as tooltip on mouseover
I'd like to put in a vote for this as well.  I've visited some sites which
practically *REQUIRE* the display of the ALT text for navigation.  While it's
nice to think that the solution is to get websites to update, there's no way
everyone will do it.  At the least, Mozilla should show the ALT text as a
tooltip either with a pref, or in quirks mode.
or may be displaying them on status bar ? it's less anoying than tooptips.
Ah, I had searched for it a number of ways, but those are 'closed' bugs, so I
guess they wouldn't have shown with the default search.

But yes, as a user, I'd definately wish to have that as an option.  I've been
adding TITLE's to my own pages (which is usually just a dup of the ALT text,
since I design it for both uses), but that won't help me with the 99% of old
pages that will never get around to such an update.  And in cases too where the
person did use it as true ALT text and didn't care about a tooltip (so wouldn't
add a TITLE even if had the chance), I would still like to be able to see it
without having to open 'Page Info' and search for the image by name.

And while those other bugs do bring up that the tooltip'ing has led to designers
'misuse' of the feature, I believe the alternative was that images had _no_ ALT
text set at all.  What if going with just TITLE ends up with the developers
setting TITLE and not putting in any ALT again?

Oh, as for using the status bar, only problem with that is often images are
links also, and show the destination URL in the status bar.  As well as any java
scripts that may alter the status bar on image mouseover.
cc ianh and hixie
We are absolutely not going to ever show the 'alt' attribute as a tooltip.
This is a done deal. Doing so would be bad for the web. See the many closed
bugs about alt text for details why (starting at bug 1995 and bug 1994 and 
looking at dependencies and duplicates would be a good start).

To quote David Baron (from bug 1995):

 Please do *NOT* display image ALT attributes as tooltips.  This encourages
 people to use ALT attributes for tooltips, which is wrong.  ALT attributes have
 a very important purpose, which is to provide replacement text for images for
 browsers that cannot or do not (by user's choice) display images, and if
 graphical browsers display them as tooltips people will be discouraged from
 using them for their correct purpose.  MSIE gets this correct.

WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Actually, this was changed to a request for a user preference setting then, so
for the many pages out there that will never be updated and that you need to see
the alt tags (or at least is a help to do so), the user can choose that.

Also, I'm using MSIE 5 right now (Win98SE), and it does display ALT tags as
tooltips, as did Netscape 4.x.

And the alternative, if browsers do stop displaying ALT tags as tooltips, will
quite probably be that most authors won't put _any_ ALT tags in at all (poor
designers aren't going to become thoughtful and great designers just because of
such a change).  I used to browse a lot with 'lynx' for Unix, and I remember
back then the page after page with just "[IMAGE]" "[IMAGE]" all over the place,
because of the no ALT tags, because designers on graphic systems had no use for
them, even back then while text-based systems were very common for the average
browser.

So even with whatever 'abuses' of it there have been, I think we're far better
off with them since they started displaying ALT as tooltips.  Without them
displaying as 'neat tooltips' the poor designers are going to take the route of
least resistance, which will be to ignore the field entirely.  Good designers
will do it correctly whichever way you do it (as long as they're informed).

I'm sorry I wasn't aware of Mozilla sooner to argue these points with you back
when it first came up, but I have to strongly disagree with those that want to
flat out dismiss this issue.  As a user, this is a feature I definately want for
the many pages that need it, and will always need it.  And as a designer I feel
it is a bad choice not to enable this because for the larger majority it will
result in even poorer designed pages, not better, no matter how much we might
want to wish it otherwise.

I hope someone will look at this with an open mind to those issues.  Or at least
address why they feel this is not the case.  Yes, I have read those other bugs
on the issue that were pointed out, but the ones voicing against it seemed to
only provide for their reason for doing so was that it would supposedly make for
better designed web pages, but I don't see how leaving out ALT tags altogether
will do that, which is what will happen instead.  So using them for an
"incorrect purpose" is better than not using them at all.

Sorry to go on so long. :-)

I agree with Jamie Wilmoth.  There are a LOT of pages that will never be fixed, 
and some of these pages absolutely DEPEND on using the ALT text for tooltips.  
And please don't even bring MSIE into it because, as Jamie points out, MSIE 
actually does use the ALT text for tooltips, if there is no TITLE attribute.  So 
if you want to point at MSIE, please at least duplicate this behavior, or 
provide a pref to do so.

At the least, please provide some way of doing this in quirks mode, since that's 
the point of quirks mode, isn't it?
Verified. WE CAN NOT DO THIS.

If you want to write a proxy server that duplicates ALT tags as TITLE, you may 
do that.
Status: RESOLVED → VERIFIED
Ok. So. If there are "a LOT of pages that [...] absolutely DEPEND on using the 
ALT text for tooltips", then I assume you mean that at least 0.001% of the web
is affected. Let's assume that the web has a billion pages. It actually has a 
lot more, but I'm being conservative here. That would mean there are maybe 
10,000 pages that are affected. Could you point me to maybe 0.1% of these?
(That's just 10 of the "many pages that need it".) If you can give me 10 pages
that would be distinctly improved by fixing this (that's under one millionth of 
a percent of the web) then I might be convinced.
Whiteboard: awaiting evidence
Well I'll leave it up to Warner Young to point out the ones he had in mind.  I
don't have a lot of specific pages, just the 90% of pages that have ALT's
whether they were meant for tooltips or not, as they're useful information about
the picture.  I have one totally offhand I could recall as a good example, that
maybe while it's the sort of 'abuse' of it, and I completely agree would be far
better as a TITLE, I can't go around forcing every web site to rewrite their web
pages:

http://www.teleport.com/~tpleger/CDD/fanart/art.html

That, and the 'archives' link at the bottom of it for another.  If you mouse
over the images with any other browser it will tell you info about the image. 
Without that the thumbnails are too cropped to tell what the pictures are, and I
don't want to have to download every image to find out what they are.

So ones like that, plus I just like being able to see what the ALT text is on
most all images, as it often gives you a name or other piece of useful
information about it (as it should), if it doesn't have some other TITLE-type
tooltip for it already.

So until we have a magic way to make the web a perfectly coded utopia, this
would be greatly useful.

Now if want to work in some incentive for coders to use TITLE, like maybe they
appear slightly larger, or appear more quickly, I have no problem with that, as
I certainly want to encourage proper coding too.  But it doesn't mean we should
make the average user (myself included *grin*) suffer to try and force some
fraction of them to do so.

cc aaronl for possible accessibilty angle.  We may want to expose this to AT
vendors, if not through an option in our GUI.  There's really no way to
distinguish authors who have purposely left out TITLEs from authors who are just
assuming that most browser users will see the ALT text. I don't think our
deciding to go along with MS on this would have any effect on lazy authors until
we get a lot more market share, but I don't think we should casually override
web standards either.
Jamie: ok, that's 2 so far... Those pages are using the 'alt' attribute almost 
correctly, actually. Personally I would say that the ideal use would be to put
the contents of their alt attribute into the title attribute, and the use alt
attribute for actually *alternative* text -- typically, in this case, describing
the kind of picture ("line art", "black and white", etc -- that's basically all
the thumbnail is telling you anyway).

Wouldn't it be even better for the author to not require the user to use a mouse
to determine what the images are though? Try using the page with the keyboard in
Internet Explorer -- you can't get the tooltips! I would have thought it would
be better to have the index contain the descriptions.

Just think -- if we made one author use "title" attributes instead of "alt"
attributes for tooltips, and use the "alt" attribute correctly on just two of 
his pages, then we have already offset the author of the two pages you quoted.
Hixie, I give up.  I know I ran into a bunch of pages at one point where I had
trouble navigating because of this problem, but either I can't find them
anymore, or they've updated their pages so it's no longer a problem.

FWIW, I still think that, as long a reasonable percentage of people are still
using NS 4.x or below, that there will be web pages that have this issue.  And
again, there are many old pages that will never get updated.  But at this point,
I think it'll probably be easier for me to wait, figure out the build system,
and add ALT tooltips to Mozilla for my own private builds, than to convince you
guys to add it.
Well having him fix it would be nice, but like I said, it can't be the user's
job to fight with every website webmaster that doesn't do the pages just as they
should be for the particular browser that user is using (though giving a few an
occational nudge doesn't hurt *grin*).  Plus these things change.  The TITLE
feild used to be for links to pages that can't have a title in the page itself
(like .txt files).  I should still have pages around where I used that even. 
Even I don't plan on going back and changing all those pages.

And here's another, not quite as significant page(s):

http://members.home.net/vmcink/vmc/

If you don't have javascript on, you have to guess at what the buttons do.  And
even when you have it on, in the Galary just like the other, mousing over the
thumbnails gives you information in the ALT, but no TITLE.

So that's another 7 or 8 pages in there, in addition to the ones I gave before.

So, if I can run across these pages by myself, with the relatively small amount
of 'surfing' I do, that's probably 1% of all the pages I've gone to in the last
few months.  So either I just happen to hit these, or there's a lot more of them
out there.

And plus, as a user, if I just need this even for one single page, then I _need_
it pretty plain and simple.  I can see why you don't want it the default, but I
can't see why you don't want to let the user have it if they want to browse with
it.  Isn't the application suppose to be a tool to help the user, not punish them?

I have contacted both those sites, we'll see if they change their sites. 
Any others?
http://www.bluesnews.com.  Their logo always has a comment in ALT text form to
indicate what it is.
At the moment, the bluesnews logo has the exact alt text that it should have in
order to be rendered in text mode (with images disabled) and does not have an
alt text which would be appropriate for a tooltip. So that site can be taken off
the list without even having to talk to them. :-)
Hixie, *at the moment*, that's true.  But it's not normally so.
Contact me when it changes.
Well, here is the first of an additional 17 pages (plus two mirror sites which
could make the total as much as 51 additional pages, though I haven't looked at
the mirror ones myself):

http://www.ki-tera.com/hollyann/art1.htm

The author spells out on an earlier page that to navigate, you mouse over the
images for information.

I think this with the previous ones brings us well over the 10 requested.

How many of those you sent requests to have actually updated the pages?

*** Bug 107954 has been marked as a duplicate of this bug. ***
Well, I have yet to hear back on my previous comment.  But now I've just run
into a case where I require this feature.  I do web page design, and for
statistics the hosting sites provide "Urchin" to report usage (and I believe it
to be a very common and wide used statistic reporting tool).  Right in their own
documantation ( http://www.urchin.com/help/en30/203.html ) it says:

   "Mouse over any bar graph element to display the actual number for that time
period."

Yet doing it with Mozilla gives no info, as they use ALT not TITLE to provide
it.  So now I can't get the details from these reports due to Mozilla's not
supporting this option.

Even if managed to get Urchin to modify their code someday, there's no telling
how long it'd take before all the various hosting sites updated their copy of it
too.
*** Bug 131354 has been marked as a duplicate of this bug. ***
*** Bug 142210 has been marked as a duplicate of this bug. ***
Maybe we should have a poll over this
Because it seams to be vert contraversial
By the way has any bodt 3rd party made a pach for this bug?
Why wouldn't the text be visible from the context menu ?

It's not even displayed in the properties dialog and that's really missing.
If it is missing in the properties window, file a bug.
Ah, so Hixie is still here.  Never did answer how many of those people he got to
update their pages.  In comment #11 Hixie said if we found 10 pages that needed
it he might be convinced, and at

http://www.ki-tera.com/hollyann/art1.htm

alone I now count 20 pages, plus all the sites that use the popular Urchin web
stats, which are probably in the thousands or more.  All that in addition to the
other sites previously listed, which appear to have shut down sooner than gotten
updated.

The status whiteboard for this bug is 'awaiting evidence' and that should be
more than plenty.  And I don't see where just having this as a pref is going to
hurt the web.  The browser is suppose to be about meeting the users' needs and
desired usage, isn't it?  Showing the ALT as tooltips in the absence of another
tooltip is the expected behavior by the user (in IE, NS4, and probably other
browsers too).

And while I'm asking questions.. :-)  I wonder if anyone ever said why they
picked the 'TITLE' tag for this behavior?  How are you suppose to set the title
for non text/html pages (such as plain text pages)?  I checked and *do* still
have pages that use the TITLE tag on the A link anchor to set a text page title
(lots of them in the top part of this page:
http://www.angel-hare.com/acorn/tta/cs/ ).  I believe the Lynx text-based
browser still follows this behavior.  Though agreed, I believe even less people
bothered with that than bothered with setting ALT tags. :-)

> Never did answer how many of those people he got to update their pages.

To my knowledge, all those that I asked said they would update their pages and
thanked me for explaining what the "alt" and "title" attributes were for.


> In comment #11 Hixie said if we found 10 pages that needed it he might be 
> convinced [...]

I'm sorry, but none of the sites you pointed to *require* tooltips, and all of
them show mis-use of the alt attribute.


> And I don't see where just having this as a pref is going to hurt the web.  

A preference will hurt Mozilla. (I'd be surprised if any UI expert said adding a
pref for this kind of behaviour was a good idea. The huge majority of users
don't know what _tooltips_ are, let alone "alt attributes" and "title attributes".


> The browser is suppose to be about meeting the users' needs and desired 
> usage, isn't it?

The layout engine is about implementing the specs.


> Showing the ALT as tooltips in the absence of another tooltip is the expected 
> behavior by the user (in IE, NS4, and probably other browsers too).

No, it's not. Showing the alt attribute contents as tooltips is a bug. We've
been over this countless times. There are hundreds of bugs in IE and NS4 that we
have fixed in Mozilla (take our excellent CSS parsing for instance). Just
because IE and NS4 do something wrong is not a reason for us to do it wrong.


> I wonder if anyone ever said why they picked the 'TITLE' tag for this 
> behavior?

That's like asking why someone picked the wheel to be round...


> How are you suppose to set the title for non text/html pages (such as plain 
> text pages)?

Eh? We're talking about HTML here.


> I checked and *do* still have pages that use the TITLE tag on the A link 
> anchor to set a text page title

And that's a valid use, which happens to also be correctly and usefully treated
as a tooltip.
Whiteboard: awaiting evidence
Sigh.  Hixie, I respectfully disagree that having a pref is necessarily a bad
idea.  I'd like to suggest making this a hidden pref, at least, that defaults to
off.  At least that way, if I *do* run across a site where the webmaster is
using ALT incorrectly in such a way that it's required for navigation, I can
turn on this pref to use the site while I file an evangelism bug on it.  Also,
just because someone files an evang bug on a site doesn't mean the site will change.
Excessive Quoting Alert!  This discussion might be more appropriate in a newsgroup.
FWIW, i pretty much agree with Hixie here, except I'm starting to doubt there is
any such thing as a "UI Expert".  IMO, even a hidden pref is questionable, since
it creates extra complexity in the code, for which there is frequently
inadequate testing; and it would get too little use to justify the cost.
Sorry if this is a bit long, but...

>To my knowledge, all those that I asked said they would update their pages and
>thanked me for explaining what the "alt" and "title" attributes were for.

Well that's good, though of the ones still up, they hadn't been so far.

>I'm sorry, but none of the sites you pointed to *require* tooltips, and all of
>them show mis-use of the alt attribute.

Well they do require it, if I don't want to have to click on every single image
to find out what it is, rather than getting the desc in the tooltip.

I don't disagree that they are a mis-use, but that's what's there and why it's
needed.  And what you asked for where ones that would be "distinctly improved by
fixing this."  And the Urchin ones to require it, as the only other way to get
the data is to 'view source' and dig for it.

>A preference will hurt Mozilla. (I'd be surprised if any UI expert said adding
>a pref for this kind of behaviour was a good idea. The huge majority of users
>don't know what _tooltips_ are, let alone "alt attributes" and "title
>attributes".

Eh?  Users don't know what tooltips are?  Even if they don't know the name, I
think they're a pretty obvious feature.  (And I suspect many know the name too,
as often apps have 'enable/disable tooltips' options, /including/ Mozilla, if
you go to 'Appearance' in the prefs.)  Though I wasn't suggesting what the UI
wording would be for this option.

>The layout engine is about implementing the specs.

So every single thing the layout engine and user prefs have are spelled out in
the HTML specs?  Tabbed browsing, password/form completion, changing font size
on the fly (ctrl +/-), blocking images, restricting javascript pop-ups, etc.? 
Every single thing is required by the specs?

And where in the specs does it say this feature may in no way be allowed as a
user accessiblity option?

>No, it's not. Showing the alt attribute contents as tooltips is a bug. We've
>been over this countless times. There are hundreds of bugs in IE and NS4 that
>we have fixed in Mozilla (take our excellent CSS parsing for instance). Just
>because IE and NS4 do something wrong is not a reason for us to do it wrong.

Agreed that just because something else does it, doesn't mean Mozilla should
have to.  But this was and is a useful and nice feature, whether it was spelled
out in the specs originally or not.  And I'm pretty sure they put it in those
browsers intentionally, not just slipped in by accident.  So more than one
person at the design level of both those browsers must have thought it was a
'good idea.'

>That's like asking why someone picked the wheel to be round...

I just meant because the field already had a different, more aptly named use.

>Eh? We're talking about HTML here.

Last I checked, Mozilla was able to display text/plain pages too.  Or is it
being stripped of all non-text/html support?  I suppose it might, if it's not in
the spec.

>And that's a valid use, which happens to also be correctly and usefully treated
>as a tooltip.

But the desired behavior is to display it on the title bar of the new page once
you follow the link to it (and bookmarking label for the page), just as if it
had been in a <TITLE> element of a text/html page.  Rather than as a tooltip on
the prior page.  (And looking at the HTML specs, they even use a simular
example, except for a gif rather than a text page, and spelled out slightly
better in the 3.2 specs under the A element.)

But the original use aside, what it seems like here is that someone just doesn't
like it, and no matter how useful or harmless it'd be, you/they don't like it,
and so no one else should have it either.

You asked for evidence of pages it'd benifit for it to be implimented, and when
given just what was asked for, decided that wasn't good enough either.

You said it would 'hurt' Mozilla, but can you give any reason how that'd be,
other than you don't like it, and the specs don't yell out requiring it to be
in?  This would make Mozilla more usable (on admittedly poorly designed sites)
and compatible with the vast majority of browsers already in use.

It would not significantly encourage poor coding since the majority of poor
coders are likely IE users too (too lazy to learn to code right, too lazy to
download a good browzer).  But I'm stuck having to view those pages, and don't
want to have to use IE to do so if possible.

And, going by the spec, 3.2 is still suppose to be supported, and under the AREA
element for image maps it defines the ALT tag with: "The ALT attribute is used
to provide text labels which can be displayed in the status line as the mouse or
other pointing device is moved over hotzones, or for constructing a textual menu
for non-graphical user agents."  And a text label can be displayed equaly as a
tooltip as on the status line (not sure if tooltips were common at the time it
was written), so using the ALT as a tooltip for an image is actually fairly
natural interpretation of those divine specs, and quite possibly where it
originally derived from.

But even though all the evidence appears to support it being a legitimate and
useful feature, I pretty much expect that'll all be offhandedly dismissed, or
other roadblocks thrown up, like needing to see it written in stone by God
first.  I haven't yet gotten one good, logical reason it shouldn't be implemented.

(Eh, it's getting way late and my typing is probably going to shot, but ya' get
the idea.)

(Also sorry for the quoting too then, as I just read Peter's comment after
trying to post this.  Yes, I spent that long working on it.)

> And the Urchin ones to require it, as the only other way to get the
> data is to 'view source' and dig for it.

Could you point me to a sample page that actually shows that problem?
I looked around their site but could not find any mis-uses of the alt
attribute. Also, if you know their e-mail address that would be
really useful, as their feedback forms seem to be designed to prevent
anyone from giving feedback.


> So every single thing the layout engine and user prefs have are spelled out in
> the HTML specs?  Tabbed browsing, password/form completion, changing font size
> on the fly (ctrl +/-), blocking images, restricting javascript pop-ups, etc.? 
> Every single thing is required by the specs?

Tabbed browsing and password/form completion are UI.

Changing font size, blocking images, and restricting pop-ups are part
of the layout engine and are done within the specs.


> And where in the specs does it say this feature may in no way be
> allowed as a user accessiblity option?

http://www.w3.org/TR/html4/struct/objects.html#adef-alt where it says
that "alt" is for "alternative text". Tooltips have nothing to do with
alternative text.


> But this was and is a useful and nice feature

I totally agree, which is why we support it in full in its standard-
compliant form, the title attribute.


> And I'm pretty sure they put it in those browsers intentionally, not
> just slipped in by accident. So more than one person at the design
> level of both those browsers must have thought it was a 'good idea.'

And they were wrong. That's what the title attribute is for.


> I just meant because the field already had a different, more aptly
> named use.

The attribute is correctly named. The title attribute has always been
for tooltips (in that tooltips have always been there to represent
advisory information about the element for which it is set). The alt
attribute has never been for tooltips (in that tooltips have never
been for alternative text).


> But the desired behavior is to display it on the title bar of the
> new page once you follow the link to it (and bookmarking label for
> the page), just as if it had been in a <TITLE> element of a
> text/html page. Rather than as a tooltip on the prior page.

The title attribute offers advisory information. The title attribute
may be rendered by user agents in a variety of ways. Using it for a
title for a bookmark, for a title for a followed link, or for a
tooltip are all valid uses of the title attribute, and may even all be
done at once.


> But the original use aside, what it seems like here is that someone
> just doesn't like it, and no matter how useful or harmless it'd be,
> you/they don't like it, and so no one else should have it either.

Should we also have a pref to handle the CSS 'line-height' property
like IE? And one for the '<link>' element? And so on?


> You asked for evidence of pages it'd benefit for it to be
> implemented, and when given just what was asked for, decided that
> wasn't good enough either.

Yep. The evidence is in my opinion unconvincing.


> You said it would 'hurt' Mozilla, but can you give any reason how
> that'd be, other than you don't like it, and the specs don't yell
> out requiring it to be in?

Unnecessary prefs hurt Mozilla by making it harder to use.


> This would make Mozilla more usable (on admittedly poorly designed
> sites) and compatible with the vast majority of browsers already in
> use.

It would also discourage authors from ever improving the accessibility
of their pages, which would directly reduce the quality of the web for
disabled users.


> It would not significantly encourage poor coding since the majority
> of poor coders are likely IE users too (too lazy to learn to code
> right, too lazy to download a good browzer).

Actually, it is quite possible that IE will eventually follow our lead
on this, as they have with many other 'features' that we have
implemented correctly (such as our strict CSS parsing).


> And, going by the spec, 3.2 is still suppose to be supported,

Actually, I don't think Mozilla claims HTML 3.2 support.

HTML 3.2 is an obsolete specification, and is well known for being
very poorly designed with respect to accessibility.


> I haven't yet gotten one good, logical reason it shouldn't be
> implemented.

To summarise, here are the reasons why this bug is marked WONTFIX:

   1. Trivial prefs lead to bad UI lead to a bad user experience.

   2. Implementing this leads to authors not using title which results
      in poor accessibility.

   3. The suggestion violates the standards.

   4. There is an easy workaround for authors.

   5. Taking a lead on issues like this encourages other browsers to
      follow suit.

   6. The number of pages adversely affected by this is small.

In addition, here are additional reasons why the proposal for a hidden
pref would also be marked WONTFIX:

   7. The suggestion creates additional complexity in the code for
      which there is inadequate testing.

   8. The cost is disproportionally high compared to the expected use.

I hope these are good logical reasons for you.
I agree with Trudelle. except that it's only getting worse, hixie seemed to 
take 'Excessive Quoting Alert!' as a green light to quote more!!

fwiw you don't need a preference for this silly behavior as demonstrated by 
debian who actually hacked mozilla to do this.

Simple conclusion:
1. anyone who wants this feature can easily get it (ask debian or search for 
Tech Evang bugs against debian for info) -- without adding pref overhead.
2. we shouldn't waste time talking about this here (feel free to flood a 
newsgroup I don't read)
If you don't want to read discussion about this then uncc yourself. It's a
VERIFIED WONTFIX bug, it's not like you'll miss anything.

This bug is EXACTLY the right place to discuss this bug. The discussion here is
completely on-topic.
IMO, bug reports should be about the problem, and how to resolve it.  Long,
extended discussions about whether it is a defect, should be fixed, why, why
not, etc. are best done in the newsgroups, especially when the participants
start quoting each other at length.  It just seems kind of silly and inefficient
to me to include exactly the same text multiple times in one bug report.
Threaded conversations are better captured in a newsgroup, and we can link
between here and there.
Okay, fine.  The bug was 'awaiting evidence' and provided that.  But that's
fine.  Also, if you're following the HTML 4 spec, it does recommend "tools
interpreting HTML 4 continue to support HTML 3.2 (see [HTML32]) and HTML 2.0
(see [RFC1866])."

Looking at it, "alternative text" also doesn't exclude tooltips.  The Urchin
stats are viewable by the various web site admins.  The page
http://www.urchin.com/help/en30/203.html shows a graphic of what the display
looks like, and let me get a sample of some source.. Hmmm, now I can't seem to
do that.  Mozilla used to show me the generated html, now getting the javascript:

parent.dLoad("12p",59,233,1115,6189906,0,0,0);

for the 12 noon bar, 59 being the height as best I can tell.  What contact info
they have seems to be here: http://www.urchin.com/company/contact.html  Which
you're right, does lead to a form only for tech support.

This isn't a do or die feature, just it was very frustraiting trying to navigate
pages that needed it.  But I've made my arguements for it, and thanks for
listening to them.  I don't have a sufficent system to compile my own versions
right now, and I like to update regularly.  Thanks at least for listening to and
adressing my arguements for it.

Good points. Besides, non-graphic browsers can use the title tag if the alt tag
is lacking due to webdesigners who don't want to include duplicate labels, anyway.
Okay, I'm quite new to bugzilla, and I hardly stopped to file the 555th
duplicate of this RFE.

Please tell me one thing: What is the disadvantage for a normal mozilla user, if
it would display these nice ALT tags every second webpage uses?

First argument: 'Hixie' don't like them.
Second argument: Its against some html4 specification detail, no normal user
knows about.
Any more?

Take this page, for example: http://de.tv.yahoo.com/grid?lineup=de&.intl=de

If you want to read the displayed program chart, you need tooltips. And why
should yahoo change the code of a page which is displayed correctly in almost
any browser, including IE and Netscape 4.x 

So, perhaps some guys should think about it again?
To quote David Baron (from bug 1995):

   [Displaying image ALT attributes as tooltips] encourages people to
   use ALT attributes for tooltips, which is wrong. ALT attributes have
   a very important purpose, which is to provide replacement text for
   images for browsers that cannot or do not (by user's choice) display
   images, and if graphical browsers display them as tooltips people
   will be discouraged from using them for their correct purpose.

Please file an evangelisation bug for the Yahoo! site.
please explain why the current ALT-tags on the German TV guide are inappropriate.

in my opinion, they're fine, they do a good job both as a substitute for an
image, and as a tooltip.  why bloat the HTML source file by duplicating the
information in a TITLE-tag?

Please read
   http://www.hixie.ch/advocacy/alttext
...specifically the introduction. The alttext in this case should be "TV" or
"(...)" or something short, because otherwise when images are disabled the
purpose of the image is lost -- it will make the table cells wider, destroying
the nice scale of the diagram.
Read the line Programers "Have a pref to show image ALT text as tooltip on
mouseover". yes, Alt text shouldent be shown as tool tips but most people do and
half these people won't change it no matter what Mozilla people do, and I agree
(now) bug 25537 shouldent be fixed. But somel bright spark had the idea of
filing this bug as a compromise so you could have a preference (off by defalt of
course) to show alt text for screen tips in sites coded in correctly but you guy
dont seem to think this is good enough. WHY? This is a great idea.
Blocks: 164421
We have too many prefs. Users wouldn't have a clue what this pref meant ("Show
text intended for when images are disabled as tooltips even when images are
enabled"? Why would they ever want that).
Hixie, "Why would they ever want that".  Same reason this bug (and all the ALT
text tooltip bugs) keep showing up.  A lot of people are simply used to this,
and expect to see it.

Of course, if ALT text would show up as tooltips to begin with, we wouldn't need
an extra pref :)
The pref would have to be in some advanced area with the text 
"Show text for not graphical browsers as a tooltip"
Summary: [RFE] Have a pref to show image ALT text as tooltip on mouseover → Have a pref to show image ALT text as tooltip on mouseover
Whiteboard: [Havecompromise]
99% of users don't have a clue what 99% of the prefs do. The argument that they
won't know what it does it pointless because when that happens they won't change it.
+1 vote to have preference option for ALT tooltip.

My suggestion for option text:
"Display ALT image text as tooltip"

That would even understandable for those users who don't know what is ALT. They
will understand, that this may display more info about the image in a tooltip.
Trust the users, they will know how to use that option :-)
No longer blocks: 164421
Blocks: 158464
Blocks: 164421
You need to log in before you can comment on or make changes to this bug.