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.

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.

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.

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.

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.

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.

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"

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 :-)