Closed Bug 25537 (NoTooltip) Opened 25 years ago Closed 22 years ago

(Warning 56k) Alt text is not displayed as a tooltip over <img> (image)

Categories

(Core :: Layout, enhancement)

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

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: rmurray, Unassigned)

References

(
URL
)

Details

(Whiteboard: See comments 31 (reasoning) or 285 (workarounds). Also, see "Document containing a summary of bug comments")

Attachments

(4 files, 1 obsolete file)

Screenshot of an alt tooltip on http://news.bbc.co.uk/ with Communicator 4.0
47.96 KB, image/jpeg
Details
For Doug comment 209
2.84 KB, text/html
Details
Document containing a summary of bug comments - Read before commenting
20.05 KB, text/plain
Details
screenshot of NY Times R.E. search results in IE feat. rollover text
168.40 KB, image/jpeg
Details
Linux Redhat version insatlled from binary RPM , ALT tags aren't being displayed as tooltips - didn't see a listing of this in the bugs, etc, so here it is, and kind of got used to this behavior in Netscape.
I don't tooltips are planned until post beta: see bug 22511
Component: Browser-General → XP Toolkit/Widgets
For 5.x, the behavior is being specified by, like, actual W3C specifications. QA Assigning to Ian Hickson who collects these bugs. ;)
Component: XP Toolkit/Widgets → Browser-General
QA Contact: nobody → py8ieh=bugzilla
Thanks Eli. The 'alt' attribute should not be displayed as a tooltip, that is what the 'title' attribute is for. See bug 1995 and bug 1994. Marking INVALID and assigning to chrisd for verification.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Keywords: verifyme
Component: Browser-General → Layout
OS: other → All
Hardware: Other → All
Summary: ALT tag behaviour → alt tags are not displayed as tooltips
*** Bug 50727 has been marked as a duplicate of this bug. ***
verifying, Hixie is right(as usual :-) we mustn't use the "alt" attribute as tooltip
Status: RESOLVED → VERIFIED
*** Bug 61222 has been marked as a duplicate of this bug. ***
*** Bug 74376 has been marked as a duplicate of this bug. ***
*** Bug 78575 has been marked as a duplicate of this bug. ***
*** Bug 79996 has been marked as a duplicate of this bug. ***
*** Bug 84066 has been marked as a duplicate of this bug. ***
*** Bug 87121 has been marked as a duplicate of this bug. ***
*** Bug 90209 has been marked as a duplicate of this bug. ***
Am I the only who think that this feature should be in regardless of what the W3 specifications says ? IE does this and Netscape Navigator 4.xx does this , and if I recall correctly Opera does this too.. It's a good feautes and webdesigners use it and have come to depend on it - there are lots of sites that employs this to some degree in their navigation Come on .. It even says on the bugzilla helper page as the very first thing : Quote : "IMPORTANT: Mozilla has two layout modes: quirks and standard. The quirks mode mimics the behavior of Netscape Navigator 4.x while the standards mode aims to comply with the Recommendations of the World Wide Web Consortium" This should definatly be a feature in the quirks mode. Ofcourse the use of the 'title' attribute is more correct, but not all pages are correct. I think the better behavior would be to support this quirk and ofcourse have the 'title' attribute overide it if present.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
From the HTML 4.01 spec: "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." In other words, displaying the contents of the "alt" attribute when we've successfully loaded the image is decisively WRONG. I'm going to rant now; reporter, this is nothing personal against you, but you've just come with this request at the wrong time. (And BTW, relying on tooltips for navigation is a very bad idea, as there are quite a few instances when it may break-my own experience does not lead me to believe that "many" sites "rely" on this.) <rant> I've been trying to put out this same brand of idiocy in bug 88297, and I'm afraid my patience has just run out. Repeat after me: "Just because other browsers do it, doesn't mean we have to." Yes, some other browsers display "alt" text in tooltips. As per the spec above, they are doing it when images CAN be displayed, and it is NOT THE RIGHT THING. If you really, absolutely, desperately have to get tooltips working across all browsers simultaneously, GIVE THE PAGE IDENTICAL TITLE AND ALT ATTRIBUTES! (because if you're willing to put "alt" in tooltips, you have higher priorities than standards compliance-which is fine, I realize that there is a "real world" out there, but when there's a ridiculously easy workaround like this, DON'T ASK US TO BREAK STANDARDS COMPLIANCE TO GET WHAT YOU WANT.)</rant> In short, don't feed this quirk; there's a perfectly good workaround for the behavior that's requested, USE IT.
I'm sorry: I was so busy ranting, I forgot to mention above that there is an alternative. If this is really important to you, despite the workaround, bring it to the netscape.public.mozilla.* newsgroups for discussion. Again, pardon the rant; as I said, it's nothing personal, it's just that this particular quirks request has been getting under my skin for some time now.
re-resolving. Please take the discussion to the newsgroups, if you wish to have this decision reconsidered.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → INVALID
There are a gazillion things about our standards compliance that annoy people, why is it that this is the one issue where the proponents of our breaking the spec are never convinced by my arguments? *pout*
Status: RESOLVED → VERIFIED
*** Bug 90821 has been marked as a duplicate of this bug. ***
*** Bug 94708 has been marked as a duplicate of this bug. ***
*** Bug 95694 has been marked as a duplicate of this bug. ***
*** Bug 96109 has been marked as a duplicate of this bug. ***
"There are a gazillion things about our standards compliance that annoy people, why is it that this is the one issue where the proponents of our breaking the spec are never convinced by my arguments? *pout*" Because most people don't really notice all the standards compliance issues (whether Mozilla is doing it right or wrong), but even someone like my Mom notices the img tooltips. :)
Twelve duplicates. Marking mostfreq. I'm not doing this so that people think it's more likely that alt text tooltips will be implemented, I'm doing this so that this bug will turn up on the Most Frequently Reported Bugs List (http://bugzilla.mozilla.org/buglist.cgi?keywords=mostfreq). Hopefully people will see it before filing more duplicates. Once again, the chance of this bug being fixed is still somewhere close to zero.
Keywords: mostfreq
*** Bug 96608 has been marked as a duplicate of this bug. ***
*** Bug 97774 has been marked as a duplicate of this bug. ***
should this still have the "verifyme" keyword? (the bug show Status:Verified, and Resolution: invalid)
*** Bug 99014 has been marked as a duplicate of this bug. ***
some other dups, individually resolved as invalid: bug 22839, bug 33931, bug 66282, bug 67093
*** Bug 100503 has been marked as a duplicate of this bug. ***
I noticed this has been reported a lot (i am guilty too, a search for "alt attribute tooltip" didn't return any of the bugs so don't blame me). Maybe there's a good reason people report this: people expect this functionality to be present and are annoyed it is not there. I don't care if it is not defined in the standard. Update the standard if you have to. Remember that people are actually going to use this thing for browsing. There's nothing wrong with defining alt tags. They are of great help for visually handicapped people and good web design prescribes that you define them. Good design in general prescribes that you something only once so duplicating the alt attributes content in the title attribute is a bad solution. I'd argue the HTML specification is misguided here. In any case, most browsers implement this and thus it is the standard.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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. ...and to quote him from bug 88297: Saying the "standard got dictated before we had a chance to rebut" is wrong. TITLE has been available for some elements since HTML 3.2 (early 1997) and for all elements since HTML 4.0 (late 1997). ALT has been clearly defined as for alternate text since HTML 2.0 (November 1995, the first standardized HTML spec). It's just a question of whether we're going to propagate a mistake made in Navigator 4.x into the future (see below). This isn't just some silly standards-compliance nit. This is one of the central points of making the web accessible to users other than those with good vision who have high-bandwidth connections over which they can load images. The trend of putting ALT in tooltips started with Netscape 4.x, and MSIE followed, although it additionally (and preferentially) used TITLE, which is appropriate for tooltips. If we continue to use ALT for tooltips it will ruin the use of ALT for alternate text which is key to the accessibility of the web, since: * Authors who want to use ALT text correctly will remove it when they see that it's causing tooltips (that don't give any additional information once you see the image) to appear in our browser. (Note that application of the ADA (Americans with Disabilities Act) to the Web, which is starting to happen, may force many authors to provide correct ALT text whether they want to or not.) * Authors who want tooltips will write ALT text (rather than TITLE text) that is not appropriate for alternate text for the images and will cause pages to appear as nonsense to blind users or users who aren't loading or can't load images MSIE for Windows has *already* been known to follow our lead on important standards-compliance issues when we take the first (hard) step and break some existing pages. IE6 will have a stricter CSS parser, greatly improving interoperability of CSS implementations. I'd guess we've had at least 10 bugs filed on the strictness of our CSS parser -- considering the numbers of users filing bugs it really isn't that many. I fully expect IE to follow our lead on this one as well if we take this step and keep our behavior as is. However, if we don't, it will be to the harm of the web at large. WONTFIX.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
I just wanted to add that I was unaware of the title attribute for img tags, and now that I see it properly displays the tooltip, I will update my pages. I think a big problem is that people got used to alt and never new the alternative title attribute. Perhaps there should be a place where webmasters can go to view mozilla specific "quirks" and be informed on what they need to do to be standard compliant.
I stumbled upon this discussion after noticing a page I had wasn't working in mozilla. I used alt's for descriptions of icons, which is a pretty common way to provide balloon help on web pages. The frequency of this usage is pretty hard to determine, because it's a very semantic thing. What has people upset about this in particular is that NS4 doesn't support title in IMG's for tooltips, despite the claims above that it's been supported since HTML 3.2. Netscape docs: http://developer.netscape.com/docs/manuals/htmlguid/tags8.htm#1310399 test cases: <html><body><img src="test.gif" title="foo"></body></html> tooltip: NONE <html><body><img src="test.gif" title="foo" alt="bar"></body></html> tooltip: bar <html><body><img src="test.gif" title="foo" alt="foo"></body></html> tooltip: foo <html><body><img src="test.gif" alt="foo"></body></html> tooltip: foo tested on Netscape Communicator 4.78 for linux x86. So the problem is that you've got to rewrite your pages for a 'one-version' upgrade of Netscape if you relied on the old behavior, with no transition period. This is the sort of behavior you want to support and deprecate, not change 'all of a sudden' and drop. It's not like Netscape supporters have been using ALT's when they could've been using TITLE's for the past few years, so it feels like a kick to the groin for 'Netscape' to say, "well, you should've been following the w3c standards," when they haven't been supported. I've changed my img classes to output alt="foo" title="foo", but I'm a mozilla fan-boy who happens to think that pendantic w3c adherence is a good thing (yes, I run the validator on everything I release). It's good to be pendantic but it's not good to require it suddenly. I'd be happy to see the support get dropped in Mozilla 2.0. :) n.b. neither is apparently supported in NS4/Mac.
*** Bug 113486 has been marked as a duplicate of this bug. ***
*** Bug 117089 has been marked as a duplicate of this bug. ***
*** Bug 117519 has been marked as a duplicate of this bug. ***
It seems to me very strange to refuse to support alt tags and at the same time be quite happy to have favicon requests everywhere, when favicon is arguably far less standard than alt. Supporting alt tags is very useful on e.g. http://news.bbc.co.uk/. It shows more information that the image and headline underneath it and lets you to decide if you want to bother clicking on it to read the story (I'll attach a screenshot from Communicator 4 to show this). If there's no title tag, I don't see why it doesn't make sense to show alt tag if there's one available. If there is a title tag then obviously that should take priority.
Dan please file a bug on evangelisation for the BBC site. For a discussion of why this bug is WONTFIX, see comment 31.
I'm using NN 6.1 (based on 0.9.2) on NT4, and alt="tooltip" displays the tooltip while alt='tooltip' does not display the tooltip. I didn't try the title tag. So this problem (as perceived by reporter) is partially resolved.
*** Bug 124132 has been marked as a duplicate of this bug. ***
*** Bug 126767 has been marked as a duplicate of this bug. ***
Engraving resolution in stone.
Status: RESOLVED → VERIFIED
Keywords: verifyme
*** Bug 129436 has been marked as a duplicate of this bug. ***
MSIE 6.0 does show ALT Text as a tooltip for images if there is no title attribute for the image. But I guess we want to do this different, and hope the whole web follows our lead. Barf!!
> But I guess we want to do this different, and hope the > whole web follows our lead. Yep. Or rather that IE follows our lead and the web just follows.
There can be a 100 reasons behind why IE beat Netscape. but the biggest factor that contributed to the fact stated above is that IE did everything that Netscape did and then some... It mimicked every feature of Netscape, created the same shortcuts for the creation of bookmarks, opening of files, etc, etc as Netscape already had. So, the transition to IE from Netscape for even a seasoned user was extremely easy. The story is the same with a lot of Microsoft products, they beat the competition by first imitating the competing product to a T... If Mozilla is to beat IE, it should do everything IE does, only better. That should be our goal; not to be different from IE. If we aspire for the latter, we have lost before beginning because right now, we want to displace IE from its perch at the top. If we are to wrest users away from IE, we must provide them with a minimal transition path, give them the same shortcuts, etc, etc. This also means, provide them with functionality they have gotten used to. Stuff like Alt + D for the address bar, alt text (deprecated but available for a short while) for images as tooltips, etc. My two cents...
> because right now, we want to displace IE from its perch at the top. We do?
Actually, IE are still copying Netscape. Look at IE6 and its quirks/standard mode, for instance. There is precendent for them following us, even with negligible market share.
*** Bug 136542 has been marked as a duplicate of this bug. ***
This is a real bug! Netscape 4.x did not make a mistake in showing Alt in tooltips. The attribute "title" in HTML 3.2 was not legal. It is often helpful to show the alternate text on images. Granted that title should get precidence under HTML 4.0 specification. But to say that Mozilla is going to be the trendsetter but the trend is to not fully display pages written under 3.2 is to ignore the world of HTML. I personally have over 1000 pages written under 3.2 and I am not going to take the time to go back and add a title attribute to the images and convert them to the 4.0 standard just to please a few people who would make great lawyers. MSIE displays those pages correctly as does NN4.0. That's 96% of all browsers that looked at my pages last week! As someone who teaches students to write HTML, I know how hard it is to get them to fill in the alt tag. The fact that it shows up as a tool tip helps to get them to fill in the alt tag. Most of the time the same wording is useful for those who use text browsers and audio browsers and those who user tooltips. Quite frankly, it is a waste of bandwidth to have to put the same text in both a title and an alt attribute. It is false reasoning to say that the title attribute is for tool tips while the alt attribute is for audio browsers. The HTML 4.0 specifications state that the title attribute *may* be used for both. I quote: "Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a 'tool tip' (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context." Just because "tool tip" is not mentioned in the alt attribute specification does not mean that it is "wrong" to use it in that way. I think that is called an enhancement. At a minimum, Mozilla should show the contents of the alt attribute as a tool tip in the quirks mode or at least give the user a place in preferences to turn that feature on. At a maximum, it should follow the precident set by MSIE. I find that I cannot unselect the "Leave as VERIFIED WONTFIX" radio button on this form, but that is not my choice. It is "Reopen CANFIX EASILY/SHOULDFIX".
> This is a real bug! > > Netscape 4.x did not make a mistake in showing Alt in tooltips. The attribute > "title" in HTML 3.2 was not legal. Quoted from the HTML 3.2 specs: "alt - This is used to provide a text description of the image and is vital for interoperability with speech-based and text only user agents." Well, it really looks like Netscape 4.x took the liberty to implement its own interpretation of the specs. Mozilla uses ALT to show text instead of image in different circumstances - either the image hasn't been loaded (yet) or image is blocked. Both Netscape 4.x and IE use ALT in a manner that is not inspired by any spec out there. Mozilla's right to correct this.
> Most of the time the same wording is useful for those who use text browsers and > audio browsers and those who user tooltips. I have yet to see a real-life example where this is the case....
I've been monitoring this bug for months now. It is amusing how the standard fundamentalists keep arguing against this. The simple thing is that alt texts are interpreted as tooltips in all major browsers except Mozilla. Therefore it is expected behavior and there's a huge amount of 'legacy' pages that won't be fixed and hence will not work correctly in Mozilla. Also the solution of educating webdevelopers won't work. If only because the tools they use (e.g. dreamweaver) don't have GUI support for title but do offer support for alt. I'd say the enormously obvious thing to do is the same as IE (and this will continue to be pointed out on bugzilla forever as webdevelopers run into this): if a title attribute is present: follow the spec. If it is absent (which is the case on most websites) but an alt attribute is present use it as a tooltip.
<QA please ignore> Commenting on this bug is a complete waste of your time, Mozilla is not going to change. If you don't like it, patch Mozilla and release your own version as Altzilla or whatever. Alt as tooltips encourages behaviour which is detrimental to accessibility. How can you *possibly* read comment 31 and still not understand this ? </>
John Levon: my problem with this is that I DO understand why the Mozilla developers feel this shouldn't be changed. I just don't AGREE with them. When coding my own web pages, I've found now that if I want an image to show as a tooltip, it's a real PITA to have to code both an ALT and a TITLE attribute. And when I get lazy, I'll just put in ALT, because at least everyone who's not using Mozilla will see it.
So what you're saying is "screw the disabled" and you want us to do the same? No thanks...
I'm not saying "screw the disabled". YOU'RE saying "screw you", and that's ME, personally. I'm a user, not a web designer. I have no influence on huge amounts of HTML out there. I just want the web to be useful. Consider DVD discs which often have subtitles in foreign languages. Since I'm not a native speaker, I find it helpful to use the English subtitles, but this is usually for the hearing impaired, so stuff like "[door slams shut]" is interspersed. In a perfect world, the DVD would contain a TITLE tag (sorry, English subtitles), but it only contains the ALT tag (sorry, the subtitles for the hearing impaired). As a user, I'm glad that my DVD player allows me to use the ALT tag even if my hearing is good.
Actually most DVDs have two sets of subtitles, one for the hearing impaired and one "normal" set. However that has sod-all to do with tooltips...
The point is that if YOU had designed my DVD player, you would have forbidden me to use the "hearing impaired" subtitles unless I turned off the audio track! This is directly analogous to my getting the ALT tags only if I turn off image loading.
If you want to get to the alternate text, we should have it visible in the properties window for the image, as well as the page info window. So that is already taken care of. (If either of those are missing, file bugs.) Tooltips are not equivalent to a secondary rendering of the content. That is a flawed analogy. The equivalent analogy would be viewing the web page with images while simultanously rendering it using audio synthesis, and that is a case I believe is quite reasonable. Tooltips are the equivalent of a set of subtitles that displays the name of each character as they appear on-screen -- that is a feature totally separate from which rendering you use for the audio track. It would be wrong to show the people's names when the user selected the hard of hearing subtitles, and it would be wrong to show the hard of hearing subtitles when the user picked the option to show character names.
Whiteboard: (see comment 31)
*** Bug 139495 has been marked as a duplicate of this bug. ***
*** Bug 140015 has been marked as a duplicate of this bug. ***
*** Bug 141997 has been marked as a duplicate of this bug. ***
Doesthis mean alternate text cant be seen after apicture is loaded? why did you write that instead of "alt tags are not displayed as tooltips" I filed a dupicate cos of that!
Alternate text can't be seen after a picture have loaded because it's not supposed to be seen. The alternate text , in the ALT attribute allows the browser to display something if the image could not load , images were switched off in the browser or it's a text mode browser (like Lynx). To display text as tooltips when you hover the mouse over an image (or any other element) requires that the author of the webpage used the TITLE attribute. Many pages assume that the ALT attribute displays a tooltip because that is how Internet Explorer does it. But IE is wrong .. the ALT attribute should not be rendered this way and if Mozilla did the same so that thoose pages could work then no one would ever bother to write correct code. Mozilla is deliberatly rendering the page correctly, forcing authors to write correct code.
Yea well the dont and it anoying and it would require more code to be written Maybe iI should complain to W3C?
This is ****. I quit monitoring this useless discussion. My point was that when in slashdot.org, I can't know what topic the article is cause they use alt and not title and the topic is just image & alt (no text). Slashdot won't fix it, and so mozilla. I'll just accept the fact that I can see the web as good as IE. b.t.w I'm not even a mozilla "user" but just test it once a while.
Check again. Slashdot uses correct alt and title text.
*** Bug 142251 has been marked as a duplicate of this bug. ***
in my knowledge of English (i am not a native speaker :) ), alternate means when one is avilable, choose another, but not both right? by the way, due to IE's mis-implementation, how many times had you seen something like "----------------------------------------------------" appears when you hover on an image? These are useful when used as an alt text, since it is a replacement for a graphical horizontal rule, however, when displayed as a tooltip, it is useless, or even annoying. If you want to provide textual explanation to an image, use title instead, as mentioned by many people before. P.S. Boris, I have crashed with your dup report ... *sigh* ...
*** Bug 142337 has been marked as a duplicate of this bug. ***
There is next to no chance of influencing the W3C to change the standard. No "fix" will (or should) come from that side. And Mozilla with not be changed to "fix" this either because if bad code worked there would be no reason to write good code and the webpages of the world would continue to be badly written. Yes , it will take a long time before webauthors see the error of their ways and start producing good code but the is nothing to be done about this. The good news is that some have begun changing their code already and have made pages that follow the standard. Amongst thoose are Slashdot though they seem to have forgotten to insert title attributes for the 5 category images at the top , although they remember to insert the attribute for the very same images further down in the news items. OK some what options do the people annoyed by the bad coding of webauthors have ? (listing the worst to the best options .. starting with the worst) 1) Influence W3C the change the standard. - No chance in hell 2) Convince the people devolping the Mozilla browser not to care so much for the standard and make a workaround for this problem - If a workaround is made , then the problem wont go away in the long run because people will continue to write bad code. - Plus Mozilla developers are stubborn :) 3) Advocate good HTML coding and one by one convince webauthors to write good code. - A big task and the best in the long run, yet it does delivered for people wanting the pages to work right NOW. 4) Use a rewriting proxy filter to insert correct title attributes for pages that lack them - This will work now - Webauthors still have to worry about producing correct code because the group of users using a rewriting proxy will not be big enough to change the need for correct code. - It however requires that you install additional software and configure it correctly So there IS a workaround for people that are very annoyed by this. Use a prxosy capable of rewriting the HTML to add correct title attributes. One popular choice is Proxomitron ( http://www.proxomitron.org/ ) .. but you can probably find more. Good places to look might be : http://dmoz.org/Computers/Software/Internet/Servers/Proxy/Filtering/Ad_Filters/ and http://dmoz.org/Computers/Software/Internet/Servers/Proxy/Filtering/ I don't run Proxomitron myself but I took a look at it's filtering language and wrote this filter to add title attributes to IMG tags without them, in order to help people annoyed by this problem. -- cut here -- Name = "Tooltip fix - disregard tag with correct attribute" Bounds="<img\s*>" Match = "\1 title=\w\2" Replace = "\1 title=\w\2" Name = "Tooltip fix - add correct title attribute" Bounds="<img\s*>" Match = "\1 alt=(\w)\2\3" Replace = "\1 alt=\2 title=\2\3" -- cut here -- I did this with the help of the language explanations and examples at : http://www.sankey.ws/proxomitron.html It's a good resource on the Proxomitron - I recommend it. Remember since I don't run Proxomitron myself I would appreciate it if someone who does run it can comment on whether or not this works To quickly detail what this filter does so you can adapt the filter to other proxies or improve or correct this one I provide commented version here: Name = "Tooltip fix - disregard tag with correct attribute" Just a name not important Bounds="<img\s*>" for any image tag.. Match = "\1 title=\w\2" .. if a title attribute is found .. Replace = "\1 title=\w\2" .. insert the very same attribute unaltered (if this first filter matches then the second filter below is not executed, so if the tag had correct code it is left unaltered) Name = "Tooltip fix - add correct title attribute" A name again Bounds="<img\s*>" for any image tag.. Match = "\1 alt=(\w)\2\3" .. if an alt attribute is found .. Replace = "\1 alt=\2 title=\2\3" .. insert a title attribute with the same value as the alt attribute Try it .. see if it works for you.
> - Plus Mozilla developers are stubborn :) sometimes stubborn is good :) By the way, Mozilla is build to evangelise standards, but not acting like a particular in order to satisfy users' needs.
*** Bug 143421 has been marked as a duplicate of this bug. ***
How about... a pref? It could even be disabled by default!
That would be (wontfix) bug 74241. Please take all "this should be a pref" discussion there.
There Probably not going to fix this. So is there a pach availible?
>....if bad code worked there would be no reason to write good code and the >webpages of the world would continue to be badly written. Should I point out that Mozilla DOES interpret BAD HTML?? If I type an opening table,tr,td, and only close out the td, I shouldn't display anything, just like NS4.x. This truly forces you to make GOOD HTML, right now, Mozilla is "making up" the rest.
*** Bug 144987 has been marked as a duplicate of this bug. ***
*** Bug 145068 has been marked as a duplicate of this bug. ***
*** Bug 145415 has been marked as a duplicate of this bug. ***
(In reply to comment 73) Thanks, CJ! This works for me: Name = "Tooltip fix (change lone alts to titles)" Bounds = "<img\s*>" Match = "(^*title=*)" "&" "\1 alt="\2"\3" Replace = "\1 alt="\2" title="\2"\3"
I have not seen a good argument for not implementing the "alt"-tag as tooltip. I know "title" is supposed to be used for this but 1. I like the extra information of the alt-text, but it is annoying to keep turning images on or off... 2. This goes for everybody that does want pictures on but will not always be able to interpret those pictures (people with eyesight-disabilities but not quite blind for example) 3. Many pages use the alt-functionality (and most likely will not change this, especially since NS4.x does NOT support the title-attribute) 4. If it is a pref, people can choose wether they want it or not 5. Be strict when composing, but loose when interpreting 6. The many comments here and elsewhere suggest that many people feel the same...
> 1. I like the extra information of the alt-text, but it is annoying to keep > turning images on or off... The "alt" attribute is not extra information. It should be exactly the same information as the "src" attribute, but in text form instead of image form. > 2. This goes for everybody that does want pictures on but will not always be > able to interpret those pictures (people with eyesight-disabilities but not > quite blind for example) I am surprised that anyone who is able to read alt text would not be able to interpret the image. > 3. Many pages use the alt-functionality (and most likely will not change this, > especially since NS4.x does NOT support the title-attribute) Evidence suggests that it is not actually that many. > 4. If it is a pref, people can choose wether they want it or not If it is a pref we are merely shoving yet another decision onto the side of the user. Most users will have no idea what the pref means and this would only serve to make our already bloated pref interface even more intimidating. > 5. Be strict when composing, but loose when interpreting That is the philosophy which brought us Tag Soup. Experience has shown that this concept does not work on the Web, because the composers are using the interpreters as a guide to how strict they should be. The stricter the interpreters, the stricter the composers will become. That is why XML and CSS have such tight parsing rules, for instance. > 6. The many comments here and elsewhere suggest that many people feel the > same... See comment 31.
*** Bug 147186 has been marked as a duplicate of this bug. ***
*** Bug 147357 has been marked as a duplicate of this bug. ***
*** Bug 147413 has been marked as a duplicate of this bug. ***
I think I should file a bug that says "Mozilla has stoped alt text as tooltips to soon as most site dont yet use the tag."
I think I should file a bug that says "Mozilla has stoped alt text as tooltips to soon as most site dont yet use the title tag." Sorry I made a mestake fist time of posting.
Alex: That's for evangelism to handle (I think).
What do you mean?
Alex: If following the standard breaks web pages, then they should be reported to the evangelism product so that Mozilla can send a message to the author of the web site that their site doesn't follow standards. From: http://bugzilla.mozilla.org/queryhelp.cgi Tech Evangelism - For reporting web pages that must be upgraded to support web standards and Mozilla.
Most of sites already use alt text for an informational purposes. Is there a place in specifications where is written "alt text must not be displayed in any way if an image is loaded completely"? I see a lot of photoalbums and articles where an information about photo is in the tooltip only. Do you really think that you CAN write a letter to every web-master, and you CAN find him, and he WILL agree to rebuild all the webpages he created??! Of course, not. So all that you do is all users and web-masters will say two things: (1) Mozilla is not back-compatible and it looses a part of information, unlike the other browsers. (2) I cannot see information about these images, and I don't want to know, is it because of your habit of ignoring users and web-masters, or because of specifications. Yes, I know, there are specifications. But web page author wants to bring information to the reader, and this reader wants to know this information. And what I see is: I open web-page, and I cannot see alt-text that contain information. Answer, please, one small question: How do you imagine what should I do when I visit a web-page? I will answer what should I do. I should read a page, open page source, and search for alt-text that is on this page. Each time I find this text I should return to the page and try to find an image assotiated with this text. These steps I should do for EACH image on EACH page. I think, this is too difficult and too long. There are two simple variants: 1) I can ignore all the information in alt-text. 2) I can use other browser. Good luck
> Is there a place in specifications where is written "alt text must not be displayed in any way if an image is loaded completely"? http://www.w3.org/TR/html4/struct/objects.html#adef-alt "alt = text For user agents [Mine: Such as Lynx] that cannot display images, forms, or applets, this attribute specifies alternate text. The language of the alternate text is specified by the lang attribute. Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users without graphic display terminals, users whose browsers don't support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc. The alt attribute must be specified for the IMG and AREA elements. It is optional for the INPUT and APPLET elements. While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines: * Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead. * Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output. Implementors should consult the section on accessibility for information about how to handle cases of omitted alternate text. title = text [CS] This attribute offers advisory information about the element for which it is set. Unlike the TITLE element, which provides information about an entire document and may only appear once, the title attribute may annotate any number of elements. Please consult an element's definition to verify that it supports this attribute. Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource: ...some text... Here's a photo of <A href="http://someplace.com/neatstuff.gif" title="Me scuba diving"> me scuba diving last summer </A> ...some more text... The title attribute has an additional role when used with the LINK element to designate an external style sheet. Please consult the section on links and style sheets for details. Note. To improve the quality of speech synthesis for cases handled poorly by standard techniques, future versions of HTML may include an attribute for encoding phonemic and prosodic information. There is no mention there about ALT not being used as tooltips, but there is about title being used as tooltips. It appears that ALT is supposed to be inline replacement text. Whether it can replace the image as it is loading or not invalid is not at issue in this bug. Bug 41924 is about for how layout handles broken images (ALT TEXT). and http://www.hixie.ch/specs/alttext excerpt: For images that have not been downloaded but are about to be and that have 'height' and 'width' attributes set, in 'Always Load Images' mode, and for all images with 'height' and 'width' attributes when the document is in legacy (or 'quirks') mode: Create a borderless box with the height and width given (interpret the height and width attributes as pixel lengths). Insert an image icon inside the placeholder (regardless of the existence of any alternative text). If there is any alternative text, then insert it after the image icon in the placeholder frame. If the frame is too small for the icon and/or the alternative text then they will be clipped, just like with the CSS declaration 'overflow:hidden'. Web sites that use ALT text for tooltips will realize it doesn't always work and adjust (especially after they read the standards - now there is a novel idea!). I 100% guarantee you will have no luck in changing any developers' minds. If you want this changed, bring it up with W3C. We do not have to accomodate people who aren't willing to follow the standards. >Yes, I know, there are specifications. But web page author wants to bring >information to the reader, and this reader wants to know this information. And >what I see is: I open web-page, and I cannot see alt-text that contain >information. Then contact the webmasters and have them fix their pages. Its not our concern. If someone takes computer hardware and builds a computer that doesn't follow the standards and therefore doesn't work, is it the hardware developers' problem that they didn't read the manual correctly (provided it was correctly outlined)? If you don't do things as people suggest, you pay the penalty. Microsoft will learn this as their browser becomes less and less popular because it breaks more and more pages.
Well. That's what you say: 1) There is no place in standarts saying that alt mustnot be displayed as a tooltip. There is only place about title. 2) If webpage was made in the times when no browser supported title text, or because of any other reason web-master used no title tooltips, it is user's problem. That's what I say: 1) There is no place in standarts saying that alt mustnot be displayed as a tooltip, but you think that it's better for millions of web-masters to remake millions of webpages. 2) Yes, IT IS user's problem. So, we think not about usability, but only about making problems for users. (That if one </table> or </tr> tag is absent, the page shouldn't be displayed.) 3) You didn't answer what should I do to get this information. I should contact EVERY web-master? Or I should use Communicator? When I see any page I cannot be sure that I see all information, so I should view page source every time. So, if I prefer to use new Netscape, I agree to loose a part of information when I even don't know what I loose. Please don't forget, we are living in real world and we make browser for the real pages. If you want to use an ideal browser for a pages made by ideal web-masters, here it is: Amaya 6.1 (http://www.w3.org/Amaya/User/BinDist.html).
BTW: You can also view the alt text if you right-click an image and click Properties.
<img src="images/dn.gif" width="247" height="33" border="0" alt="some text"> I right click and get no alt text. <td height="18" align="right" valign="bottom" title="other text"><img src="images/dn.gif" width="247" height="33" border="0" alt="some text"></td> I right click and get title text. (2002060408) And even if I could get alt text this way, should I right click and call properties for every image on every page?
I personally am now satisfied that this behavior is exactly as it should be, and the best solution/work around (short term anyway) that I see here is point 4 of comment #73. The simple-minded question I therefore come up with is: Is it too much bloat/too confusing to add a pref to duplicate alt text into title text as the page is read?
May be you don't understand it now, may be you cannot beleive, but 99,1% of webpages with alt tooltips will never be corrected. I'm very sorry.
Can I say I no longer sta#nd by what I said in comment 67 It was before I'd herd of the title atribute.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Oops sorry I dont know how I reopend this I never thought I havr the right
Alex Hosking, please stop spamming the bugs. The newsgroups are the appropriate place for most of your comments.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
hehe
Status: RESOLVED → VERIFIED
Resolved? This really sucks
A related problem is that some web page design software doesn't use the title tag. One example: Mozilla Composer... :-)
*** Bug 150825 has been marked as a duplicate of this bug. ***
*** Bug 152813 has been marked as a duplicate of this bug. ***
This ought to be fixed. Mozilla supports "tooltips" in the < acronym > tag (which nobody uses). This means it can be fixed, the code is there. Also, ALT is a standard attribute of < IMG >, in all HTML standards, eg: http://www.w3.org/TR/html4/struct/objects.html#alternate-text This means it should be fixed as well.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Try reading the bug Mr. Joseph Brown
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
suggested reading: comment 31 and comment 95 for example. v.
Status: RESOLVED → VERIFIED
May be somone should file a tech evangelism bug to say "2 billion pages need to be changed to support the title attribute even those realy old pages that will never be changed". I think there should be th option to have alt text desplayed as tooltips an option that would be off by defalt I realy dont think there is any reason not to do that. As some pages (well at least half of them) Will never be changed.
Yes, and there is no place in standards saying "alt text shouldn't be displayed as tooltips". And what about back compatibility? I know, Mozilla displays incorrectly NOT every page that is not completely made with standards support.
*** Bug 155101 has been marked as a duplicate of this bug. ***
Alex your are right. "2 billion pages need to be changed to support the title attribute !!" IE Support ALT-Tag as tooltip Mozilla NOT - for Standard-User it&#180;s a Bug ! IE has a Browserquote of > 80% from all Users. No one change his webpage because W3Org and for 3% Mozilla-Users. Here decides not the standard or the W3C here separates that which the majority expected. ALT-Tag as Tooltip - or the most Poeple use IE ! ps.: Try it: write the webmaster from CNN.com to use title as Tooltip tag - good luck !!!
With a few minor exceptions near the end, CNN.com uses perfect alt texts throughout, and uses title attributes where they wanted tooltips. So it appears that CNN's authors have already been convinced.
Those of you who desperately want alt attributes shown as tooltips in your own presonal builds, btw, should look into the following Mozilla extension: http://www.cc-net.or.jp/~piro/xul/_popupalt.html
*** Bug 157972 has been marked as a duplicate of this bug. ***
Alias: NoTooltip
*** Bug 158478 has been marked as a duplicate of this bug. ***
Hixie (if I may), you seem to be the (currently) most vociferous proponent of this current aberrant Mozilla behavior regarding the rendition of web pages made to the older standards. Why have you ignored the very cogent comment #51? Perhaps you didn't ignore it and I simply missed your response in all the noise? Why is it a good thing for Mozilla to retroactively invalidate pages? I can see the point of "encouraging" good code from henceforth, but very many pages were made completely (at least in this regard) in accordance with the standards in place at the time. To what good purpose is "quirks" mode if not for such as this? This particular stance taken upon your interpretation (i.e. your limitations which enhance even the current language) of the spec is quite interesting in comparison to the silent conjuring of closing (table, &c.) element tags which is currently performed by Mozilla (as noted in comment #96). Granted, in that matter (error conditions) the spec does not offer guidance regarding what to do with the data, but it does plainly recommend further indication (not being silent) regarding whatever action is eventually taken. [In fact, the language there is far clearer in it's implications than that which pertains to the alt attribute.] As it stands at this time, I can never know if the page I'm viewing in Mozilla is supposed to be structured in that manner or not. That's another (active) bug, but I bring it up as a point of reference to indicate the inconsistency in this matter of strictness. In comment #85, in response to item 4, you state your opinion that the preference interface is already too bloated and that users should be spared such decisions. I don't know how to break this to you, but the preference system is actually horrendously spartan, at least in it's present form! I should think that nobody would think less of you for stepping out of the corner you've backed into on this matter. Older pages which adhere to the standards in place at the time should be rendered as per the practices of that time or the historical perspective will be detrimentally altered.
Good. And please remember: Mozilla is not the system the only function of which is to train web-masters... What is following the standard for 1000 web-masters, that is INCOMPATIBILITY for 1000000 users. So, we just want to ignore all the users, noone of which can contact to ALL the web-masters of ALL the pages that he visit. Thank you.
*** Bug 159698 has been marked as a duplicate of this bug. ***
*** Bug 159831 has been marked as a duplicate of this bug. ***
Summary: alt tags are not displayed as tooltips → alt text is not displayed as a tooltip
Has anyone thought of evangelizing HTML editing applications, not just websites? Take a look at: http://www.fogcreek.com/CityDesk/help/Editing_Articles/InsertingPictures.html This is an HTML editor. 3 points to anyone who can spot the issue with the image in the center of the page. I'll give you a hint: it has to do with ALT text. ;) No wonder everyone thinks ALT text should be tooltips. As an aside, is there any reason why Mozilla doesn't display ALT text as tooltips when in quirks mode? I mean, the entire point of quirks mode is for Mozilla to break standards in order to avoid breaking older pages, right? We can assume that people who create new pages according to the standards will use TITLE text for tooltips, but older pages which were made before the TITLE attribute was invented use ALT for that purpose. I don't see the difference between, say, quirking table layout in quirks mode, and quirking ALT text display when in quirks mode. Obviously not in standards mode though.
*** Bug 160245 has been marked as a duplicate of this bug. ***
If you can fix bugs like bug 156979 to make Pages that use the marquee tag look right then why not fix bug 74241 To stop all these arguments (its called a compromise). I now after learning what I've learned and reading comments explaining why this is wrong think this bug shouldn’t be fixed BUT bug 74241 should be as long as the preference is off by default. Because lets face it even If most people do start using the title attribute Some people wont and most older pages will never be changed.
Alex Hosking: If you or someone else you find will spend the time to fix this bug and hook it up to a pref for prefs.js, then its quite possible it might be put into the tree or you can just distribute it using an XPI. Engineers are not going to waste their time, though, writing code to help nonstandard pages when we are still working on making Mozilla the most standards-compliant browser and have a huge list of high priority bugs. As you can see, it would be quite in conflict with what we are trying to achieve. Therefore, unless you can find a developer to work on this, it will never be fixed. There are a hundred or so people that do almost 50% of the work for this project, and they work their butts off. There are probably another 5 million people in the world with the kind of programming skills to implement what you want done. Find one of them. ;-)
Brian, if I recall correctly, even getting someone to write a patch for this won't get it checked into the tree. There was a bug filed to do this just for embedded versions that was canned anyway. The only hope is to create your own branch, but the effort involved with keeping that branch up to date all the time would be prohibitive.
*** Bug 161457 has been marked as a duplicate of this bug. ***
*** Bug 162560 has been marked as a duplicate of this bug. ***
*** Bug 162820 has been marked as a duplicate of this bug. ***
I'd like to request this bug to be opened again. It is closed because it doesn't follow standards but I quote: " Some might argue that this is a 'horrible' thing to do to a standards based client such as Mozilla and to a certain extent I agree. However, we do already support a number of very useful IE proprietary extensions especially with regard to the DOM HTML and DOM Style. In fact, the standards alone do not make for an easy authoring environment." < http://bugzilla.mozilla.org/show_bug.cgi?id=156979 > Therefore I would like to review the consequences of implementing the alt-text again, but now without the 'standards-compliant' part and just with looking at its use, benefits and drawbacks.
If you are forced to use a web page that is unusable without tooltips, and which is created by a fool who thinks that the way to generate tooltips is with the alt attribute, then you may apprecite the following: WORKAROUND Create a bookmark with a name like "Fix tooltips for broken pages" a set its location to the following Javascript URL: javascript:(function(){function altToTitle(d){for(var i=0;i<d.images.length;++i)if(d.images[i].title=="")d.images[i].title=d.images[i].alt;}altToTitle(document);for(var f=0;f<parent.frames.length;++f)altToTitle(parent.frames[f].document);})(); This long URL should be all on one line, but bugzilla will probably break it up. If necessary, put it back together. Now, when you get to the broken page, select this bookmark from your bookmarks menu (or sidebar, or personal toolbar) and, as if by magic, you will have tooltips. HOW IT WORKS Very simple really, it checks out all the images on the page, and if the title attribute (the one that should be used to generate tooltips) is blank, then it copies the contents of the alt attribute into the title. It even works on framed pages. Not perfect, but probably enough to let you use the web page in question, and move on to somewhere nicer.
Interesting fix, Tim. I may incorporate a mention of it into a future revision of the recently-published "Defining Cross-Browser Tooltips" (http://devedge.netscape.com/viewsource/2002/tooltips/), if that's all right with you.
*** Bug 163411 has been marked as a duplicate of this bug. ***
Response to comments in dupe bug 163411: > ------- Additional Comment #4 From Peter Jacobi 2002-08-23 01:14 ------- > I just can't get it, why doctrine must win over usability. If we keep our current behavior, authors will eventually learn the difference between alt and title. If we display the contents of the alt attribute as a tooltip, authors will continue to use it for that purpose, making many pages unusable for people using speech browsers. I prefer a minor temporary annoyance for users with normal vision to a permanent major usability problem for blind users. > - the affected pages (having only alt but not title attributes for > img) are (or can be, if not broken for other reasons) perfectly valid > HTML. So it's not a request to render broken pages If they use 'alt' for tooltip purposes rather than for alternative text, they are *not* valid HTML. Not all errors can be detected by the W3C validator, just like a computer program's spell-checker is no match for having the document proofread by a person. Take this quiz: http://ln.hixie.ch/?start=1029524973&count=1 The answers are here: http://ln.hixie.ch/?start=1029713028&count=1 Unless you pass that quiz, do not talk about what's valid markup and what's not. > ------- Additional Comment #5 From Peter Jacobi 2002-08-23 02:45 ------- > > Jonas, All, > > Take a look at: > http://www.fwtwr.com/fwtwr/puerto_rico/184game.htm > (and compare using a browser which shows tooltips) > > This page is effectively broken when the alt tooltips > aren't displayed, as they give vital information about > all items on the game board. > > And yes, I contacted the author, and he was even positive > about changing, but has a big practical problem about out it, > because the pages are generated by a program he cannot easily > update. And the pages are generated too often for hand changing. Yeah, this breaks pages. So does not supporting ActiveX. > BTW: Does anybody has XSLT for duplicating the alt attribute of > all img elements into a title attribute? Comment 133 contains a bookmarklet.
>> BTW: Does anybody has XSLT for duplicating the alt attribute of >> all img elements into a title attribute? > Comment 133 contains a bookmarklet. Yes, but that's for the viewing side. I'm looking for a solution which can be used on the authoring side, when the program generating the alt-attributes cannot be updated. > Yeah, this breaks pages. So does not supporting ActiveX. But allowing ActiveX is obviously a big mess. Displaying alt-tooltips when no title attribute present, would only require to step back from doctrine. Also, I gave the example only because you said it wouldn't break pages. > If they use 'alt' for tooltip purposes rather than for alternative text, they > are *not* valid HTML. Not all errors can be detected by the W3C validator, The HTML 4.01 REC is very sparse on the use of tool tips. It states at two places, that the title attribute may be rendered as tool tip. (not SHALL). It doesn't state anywhere which information shall not (or even SHALL NOT) displayed as tool tip. This is perfectly OK, as it's part of the browser's user interface and not in the domain of the REC. Likewise there are no SHALLs and SHALL NOTs what to put in the context menus, etc. > If we keep our current behavior, authors will eventually learn the difference > between alt and title. If we display the contents of the alt attribute as a It's not the author, its the user! Did you read the Slashdot post [1] from Monte Hurd? Evangelizing the authors is no substitute for giving as much usability as possible. It's been said over and over again on this topic: There are zillions of historical pages which would be better usable when displaying the alt-tooltips and there are practical problems for authors, which are aware of the difference, but rely on old tools. > I prefer a minor temporary annoyance > for users with normal vision to a permanent major usability problem for blind > users. The example page I provided [2] profits from displaying the alt-attributes *and* from reading them to blind users. It may be even better when using alt and title attributes, but pages which are effectively broken without displaying the alt-attribute typically have alt-attributes that are worth reading to blind users. [1] http://slashdot.org/comments.pl?sid=38425&cid=4113817 [2] http://www.fwtwr.com/fwtwr/puerto_rico/184game.htm
As my previous comments were rather long, I'll like to give a summary: I see only two non-comprimises reasons for not giving the users a page rendering, he used to have in the past: - security (ActiveX) - would make standards conforming pages not work/look bad (as the box model issue which was resolved by 'near standard mode') Bug 25537 fits neither description Evangelizing authors is a separate issue and shouldn't be done by punishing users. At least not by punishing them badly.
Refusing to display ALT attribute text as tooltips, in the _vast_ majority of cases, doesn't adversely affect users of graphical browsers at all. Even the majority of the very worst developers of non-standard code or inaccessible layouts don't solely rely on ALT text being displayed in tooltips. Allowing it to be used as tooltips, weakens TITLE, which is already intended for this purpose. As of yet, I haven't seen people argue that LONGDESC, BORDER or any other non-ALT IMG attributes available should be displayed as tooltips. You could no doubt equally argue that a cascade effect should be applied to them as well. Perhaps even so with other elements such as anchors, etc. However, this eventually goes _against_ usability. Soon enough you have tooltips on everything, obscuring the actual content. I suppose another line of thought could be that we shouldn't be showing _any_ tooltips at all... Allowing ALTs to be displayed as tooltips (in the absence of a TITLE) might well be an extension, but a superfluous one, and one that conflicts with existing elements. There's no _need_ to take on this behaviour and, in the interests of correctness, I don't think we should.
Marcus, All, > Refusing to display ALT attribute text as tooltips, in the _vast_ > majority of cases, doesn't adversely affect users of graphical > browsers at all. Why do all GUIs known to mankind display tooltips for their graphic buttons? This is a strong, valid use case for this feature. Apart from this major use case, tooltips are incredible useful for games, where you can't put all information on screen but want them available without another server access. > Even the majority of the very worst developers of non-standard > code or inaccessible layouts don't solely rely on ALT text being > displayed in tooltips. Using alt instead of title in hope for having a tooltip displayed doesn't violate the HTML 4.01 REC. You won't find a triple {"alt attribute", "SHALL NOT", "be displayed as tool tip"} in the REC. The REC remains silent on this. But prior art has lead to a large number of pages which use alt for tooltips. And most old pages will not be updated whether Mozilla supports them or not. > Allowing it to be used as tooltips, weakens TITLE, [...] It's against the Genova Convention to evangelize authors by taking users as hostages.
> It's against the Genova Convention to evangelize authors by taking > users as hostages. Users are not being held as hostages. On the contrary. I, as *a user*, am sick and tired of seeing stupid tooltips pop up everywhere when browsing with IE. Take Google for example. Hover your mouse curser over their logo, and a tooltip will pop up and say "Google". What good does that do? Unlike IE, Mozilla does not take the users as hostages in order to be compatible with old, broken web pages.
Jonas, All, I'm sure we can get near consensus. I understand your concerns, but I also suggest you concede, that bug 25537 is not about HTML REC conformance, as was claimed so often here. > Unlike IE, Mozilla does not take the users as hostages in order to > be compatible with old, broken web pages. A browser's behaviour is not completely given by the HTML REC, and for the good! The REC doesn't say anything about what to display in a context menu and is only suggesting that the title att is to be displayed as tooltip if present. For argument's sake, there may be a minor use case for displaying Mime type, dimension and filesize of an image as tooltip (on special request from the user, I suppose), and nothing in the REC forbids or endorses this. So it's bogus to denounce pages, which hope that their alt attribute is displayed as tooltip, as 'broken' or 'non confirming'. They rely on prior art, and yes, new pages should use title, but there is no reasons to throw the old pages out of the boat. > Take Google for example. Hover your mouse curser over their logo, > and a tooltip will pop up and say "Google". What good does that do? Take Slashdot as example. Did you grok all 'topics' icon the first time you saw them? Displaying the alt attribute as tooltip would have helped. If your GUI would have the option to turn off all tooltips (or tooltips for application written prior some date), would you turn off them?
As argued to death, this is not a bug with Mozilla's behaviour. It should be INVALID as originally set by the assigned QA, but it's now VERIFIED WONTFIX. It's been re-set to this numerous times by Mozilla QA and would be again, if necessary. Representatives from Mozilla and Netscape have made it clear that ALT tooltips are not going to be implemented. (There are various workarounds for the individual user including simple bookmarklets, local patching or even creating separate Gecko-based browsers with ALT tooltips built in as default. The beauty of open source.) As was mentioned way back in comments #15 and #16, and more important than any point made here, any further discussion should really be taken to the newsgroups.
=========== Let's outline the issues: ================== 1. W3C standards compliance. The HTML standard doesn't say not to use alt in tooltips. W3C specs also include the concept of repair, where a user agent such as Mozilla can repair missing content. I think there is a draw between the 2 camps, and we should really be concentrating on the end-user issues when making this decision. Advantage: neutral. 2. Concern that we're punishing authors who are correctly writing good alt text, and correctly understanding the difference between alt (an image replacement) and title (for tooltips). I would like to see a realy world web page where we're negatively impacting the usability because we're bluring the distinction. Advantage: possibly no_alt_tooltips. 3. Irritation at tooltips, especially redudant ones. IMHO, tooltips are a fact of life, and they're often quite redudant. One can't get too irritated at them anyway, and I think they can be turned off in system prefs? Jonas, do you get irritated by toolbar tooltips as well? Advantage: neutral, tooltip redundancy is a fact of life. 4. Does the usability of sites get enhanced by showing alt as tooltips? I think the real world example of Slashdot topics is a great one - I did that too. No one can say that wasn't useful. I think the no-alt-as-tooltip folks need to provide a real world web page example for their points that clearly shows the usability of the site is diminshed. Is that issue as big as the Slashdot topic issue above? Advantage: alt-tooltips. 5. The concept that if we stick to our guns, the web will evolve to do the right thing. HOWEVER, title vs. alt is too subtle of a distinction for most authors, and old pages won't change. I think those points neutralize the argument. Advantage: neither side. 6. The fact is that most people see this as a bug in our Gecko, not in IE. Advantage: alt-tooltips.
*** Bug 164291 has been marked as a duplicate of this bug. ***
Yes, I agree with the above. I am trying to get more people to use Mozilla or Netscape 6 in my organization. But, I just discovered that if I turn images off in Mozilla 1.0 and reload the page, the "alt" text is not showing in place of the images. Not good. The "alt" attribute isn't deprecated in HTML 4.01 and should still be supported. I work for a Federal Gov't organization which is very sensitive to Accessibility (by law) and Section 508 compliance. This is a must have for my agency and the thousands of web pages using the "alt" tag that we have. I hope this can be resolved. Thanks.
Yes, I agree with the above. I am trying to get more people to use Mozilla or Netscape 6 in my organization. But, I just discovered that if I turn images off in Mozilla 1.0 and reload the page, the "alt" text is not showing in place of the images. Not good. The "alt" attribute isn't deprecated in HTML 4.01 and should still be supported. I work for a Federal Gov't organization which is very sensitive to Accessibility (by law) and Section 508 compliance. This is a must have for my agency and the thousands of web pages using the "alt" tag that we have. I hope this can be resolved. Thanks.
Jon: > But, I just discovered that if I turn images off > in Mozilla 1.0 and reload the page, the "alt" text is not showing in place of > the images. Not this bug. You're looking for bug 1924. Aaron: You forgot to include the most important issue of them all, namely that displaying alt text as tooltip discourages authors from writing proper alternative text, causing pages to be unusable for blind users. > Jonas, do you get irritated by toolbar tooltips as well? When the toolbar is text+icons or text only and the tooltip says exactly the same thing as the text, yes. When the toolbar is icons only or the tooltip provides additional information, no. > Does the usability of sites get enhanced by showing alt as tooltips? I think > the real world example of Slashdot topics is a great one - I did that too. No > one can say that wasn't useful. But they could have used 'title' instead. Filed evang bug 164312.
Make that bug 41924, not 1924. Sorry.
Okay, I'll do that one: 7. The concern is that diplaying alt text as tooltips discourages authors from writing proper alternative text, causing pages to be unusable for blind surfers. We need a concrete example of this. Show me real web pages where the alt text was written to be a tooltip, thus impairing accessibility for blind users. We've given slashdot an example of how usability is impaired by not displaying alt as tooltip, and we the no-alt-tooltips people to provide the same. I assert that the problem with the web for blind users is the lack of any text equivalents, not that people are writing poor text equivalents because they wanted it to be a tooltip. Having alt show up as tooltip actually makes the web more accessible to blind users, because they are then visible, so people remember and care to write them, Therefore, item 7 is not a reason for no-alt-tooltips.
I'd like to add that not showing ALT as tooltips because it encourages bad HTML is only valid if Mozilla will actually cause people to change their HTML coding. Many people won't change their HTML, because their page works "correctly" (that is, ALT shows as Tooltips) on *all other* browsers. No matter how much evangelizing you do, people will always *perceive* this to be a bug in Mozilla, not as a standards compliance issue.
> Many people won't change their HTML On the other hand, many people _will_ change their HTML exactly because of it. ALT attributes of various websites I'd created not showing in Mozilla was the first thing that made me start to really look around to find out why - making me for the first time actually _read_ the W3C docs. Before, I'd write HTML haphazardly - making sure it worked in Netscape 4.x as closest thing to the lowest common denominator and then tweaking just a bit until it also looked good in IE. Now, I really know what I do, and am in the process of redesigning a few thousand pages to actually observe standards. Also, don't forget Mozilla is *known* as the browser closest following the standards and supporting most of them, and is consistently portrayed like that by most media. If something doesn't show up as expected in Mozilla - even if it does in all other browsers - a lot of people _will_ first think that the way Mozilla does it is the right way and figure out what exactly other browsers are doing wrong.
Before going further on this bug, please follow this algorithm: DO Do not add a comment to this bug Read comment #31 Do not add a comment to this bug Read comment #133 Do not add a comment to this bug IF you understand the reasoning behind the WONTFIX THEN EXIT DO Read every other comment in this bug Do not add a comment to this bug IF you understand the reasoning behind the WONTFIX THEN EXIT DO LOOP Please only add a comment if it has some amazing piece of information we just can't do without! I am sick of all the spam I am getting from this bug. This bug is a WONTFIX. It will stay a WONTFIX forever unless W3C changes the specs. Its not our fault that IE supports invalid HTML and that people have to rewrite their pages because of this. You can probably write a perl script that will go through your HTML directory tree and replace the ALT and TITLE attributes for each image automatically. You should also realize that if you put the TITLE tooltips in the ALT area, it could mess up text-only browsers like Lynx.
Whiteboard: (see comment 31) → (SEE COMMENT 153!!!)
*** Bug 165451 has been marked as a duplicate of this bug. ***
I would like to point everyone who - like me - is highly anoyed by the lack of tooltips to the allready mentioned link http://www.cc-net.or.jp/~piro/xul/_popupalt.html The extension works as expected although the installation on linux is not that straightforward. - Make sure you enabled "software installation". If you are as suspicious as me you will probably disabled it and will not be getting any error message to indicate that. - Check permissions on ../mozilla/chrome/popupalt.jar (only 1870 bytes btw.) The installer sets them to 400 not 644 so nobody except the superuser gets any tooltips - Restart your browser and voila everything is back to normal - You _do not_ have to build mozilla for yourself to make this work. The original comment #117 did not make this very clear (at least to me - see ps). mfg. j.bernau Ps: Sorry for the bad spelling but i'm not a native speaker
*** Bug 167113 has been marked as a duplicate of this bug. ***
You might be interested in bug 149157. The problem: ALT text doesn't fit in a broken image placeholder. The solution: Draw a tooltip (still open to discussion, of course). However, I've proposed that the tooltip (or a "titletip" as one called it) be drawn only when the ALT text doesn't fit in the placeholder, and never after the image has finished loading. Your comments and suggestions on how to solve the cropped ALT text problem are welcome on that bug. (Before changing the bug, please read bug 149157 comment 6.)
*** Bug 167975 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Just filed bug 172253, RFE: show alt text in status bar.
Until I found this thread, I thought that ALT texts are not displayed as tooltip, just because Mozilla is in early phase, and this is a bug (it will be corrected, I thought). Even after 1.0 and 1.1 releases, I was hoping to find this feature. But nothing. Now, that I found this thread, I know the reason, and the official opinion. And I'm very sad :-((( Being a webmaster I need ALT text to be displayed as tooltip for my users! Please read my comments: 1) Before anybody yields me, that I post a new comment: I did read COMMENT 153, COMMENT 31, COMMENT 133, and other comments, too, but I did not changed my mind. Most comments *wants* ALT text as tooltip in Mozilla (and dups proves that, too)! Therefore I also post my reasons. BTW: you should also read Comment #47 and Comment #33, which are correctly explaining why is this ALT toltip support so important! 2) If this bug has 160 comments, filled mostly with dups, and with comments which *are* asking/voting for ALT text as tooltip feature, Mozilla developers should observe the high demand for that feature, and provide that ALT tooltip feature until the market leader IE also provides that feature (temporarily)! 3) 98% of my users use either versions of MS IE or Netscape! Mozilla is somewhere below/around 1% :-((( (ok, true, that NS 6.x, has Gecko/Mozilla engine) I like Mozilla, and would like to support/recommend Mozilla to my users, but *I WILL NOT RECOMMEND Mozilla, until* it displays something completely differently comparing what 98% of my visitors see. (Currently I suggest Netscape 4.x for my users, tough I do crossbrowser site). If I change ALT to TITLE my Netscape visitors will NOT get the same result, what IE visitors get. (The percents are just for example, +- a few percents. Mainly it covers a closely correct market share) - Until the Mozilla developers will deny implementing ALT tooltip: a) I will not make Mozilla compatible websites, b) I will slowly stop using Mozilla, and go back to the ALT tooltip supporting browser group presented by Netscape, IE, and (likely?) Opera. Why? Because when I load a page in Mozilla, I have to open the same page in IE or Netscape to see the tooltips on several websites. So it's better to load right in Netscape or IE, isn't?... 4) While I want to provide crossbrowser compatibility, I will not increase the page size by doubling texts using both ALT & TITLE attribs. For several websites this would be considerable size increase, where there are a lot texts in tooltips. So I will NOT use both ALT and TITLE, because it is waste of space, as I described! 5) Most browsers support ALT text as tooltip, even if it is not in the standards! TITLE is not supported by all browsers (i.e. Netscape)! IE does well correctly, it displays ALT as tooltip if TITLE is missing, and displays TITLE if both or just title exists... That's the correct (while I aggree, temporary) solution. I do not like IE, but I think this is the correct solution. 6) It seems I have to choose between Netscape-ALT and Mozilla-TITLE, if I do not want to increase page size. And since actually Mozilla means very few visitors, I will keep supporting Netscape & IE visitors mainly and will use ALT tag for tooltips. 7) I do not bother about the standards, if I can show same design result for 98% of my visitors! The truth is, that the "standard" is, to display the ALT text as tooltip. That's the 98%. The ALT tag and its tooltip display relation *IS a HISTORICAL feature*, rather than standard feature, and even the older sites used & still use this feature. (I aggree standards, but I hate things what are illogical, and wants to change things/traditions suddenly, without any temporary interval. And Mozilla is sticking to the standards, without considering to have the ALT tooltip feature, until the market leader browser, IE also has. So Mozilla should support it in quirks mode, rather than standard mode. This was stated clearly in Comment #13!) 8) I will not apply the *workaround*, because I need ALT tooltip support as base feature of Mozilla, until IE also support it as base feature. I do not want to apply patches! (although I'm glad, that the patch exists, and those who wants can apply it) 9) What IE can support temporarily, why can not also support Mozilla? Until IE support ALT text tooltip, why can not Mozilla support until that time? Mozilla/Gecko is NOT yet leader of the browser market to be leader of standard following, especially in case when most of the websites use ALT text as tooltip display!!!... 10) Keep posting to this thread! Hopefully Mozilla developers will change their mind sometime in the future, thanks to the popular demand. This thread is 2 year old. Maybe another 2 year and additional hundreds of comments will be enough to convince the Mozilla developers, that there is really a popular demand to support *TRADITIONAL features* until market leader browser support it. Please, users who also wants this ALT tooltip feature into Mozilla, place their votes for this bug! I placed my vote, and I will leave it here until. Thanks! Best regards, Webmaster33
In reply to comment #160, I would like to ask everybody if there is any browser at all besides NS4< that does not support the use and display of TITLE. As far as NS4 is concerned IMHO clearly Netscape has released a better more portable smaller memory footprint browser based on Gecko that supports TITLE and a huge number of other standards as compared to the previous NS4. Therefore NS4 should be considered obsoleted by the newer versions of the browser. So, is there any browser that really justifies the use of ALT rather than TITLE for tooltip display? If not, may I point that comment #160's argument is moot.
>So, is there any browser that really justifies the use of ALT rather than TITLE >for tooltip display? If not, may I point that comment #160's argument is moot. Netscape 4.x *WAS* the standard browser since 1997 for a looong time. There are millions of websites based on the ALT tooltip feature and to be was designed to be Netscape 4.x compatible! (actually NS 4.x has about the same number of users like NS 6.x) The only fact that *does matter*, that Mozilla/Gecko and such way Netscape (which uses Gecko engine), cuts a tradition, what was traditional for several years (since about 1997). Even Windows was backward compatible (at least partially) because of traditional compatibility. With NT/XP MS did cut this tradition. Correctly. But there was a long time left for the users, to switch to new technology and age out the old traditions. Mozilla/Gecko makes/made suddenly unusable (partially) those old websites, which are still using ALT tags as tooltips. There are millions of such websites! It is nonsense to force a lot of web developers to change their website to keep compatible with new browsers & standards!!!... You can not force users/webmasters to redesign/change their site! Does Mozilla want to be like Microsoft, who uses its monopol position to force to change things? Not to mention Mozilla is not in that (monopol) position :-) That ALT tooltip compatibility is so small thing in the Mozilla/Gecko engine, that should not be a problem to support traditional compatibility until IE also does also support it. I checked my website (small one tough), and created a statistics (based on 2002 September data) about users who can or can not view ALT/TITLE tooltips: ---------------------------------------- Following users CAN view TITLE tooltips: MS IE 5.x+6.x (88.61%), NS 6.x+ (1.43%), Opera 6.x (3.93%) = Overall (93.97%) Following users CAN view ALT tooltips: MS IE 5.x+6.x (88.61%), NS 4.x (2.12%), Opera 5.x (0.49%) = Overall (91.22%) Following users can NOT view TITLE tooltips: NS 4.x (2.12%), MS IE 3.x, 4.x (3.22%), Lynx (0.2%) = Overall (5.54%) Following users can NOT view ALT tooltips (because of Mozilla/Gecko engine): NS 6.x+ (1.43%), Opera 6.x (3.93%) = Overall (5.36%) ---------------------------------------- Only 2.75% more users can view TITLE tooltips than ALT tooltips in overall. Only 0.18% more users can NOT view TITLE tooltips. What does this mean? There is almost no difference between TITLE and ALT display possibilities. This means, that NO MATTER if the standards does not support ALT as tooltips or not. Not to mention that NS 4.x (2.12%) is still more than NS 6.x+ (1.43%). NS 4.x is still significant version within the Netscape versions!!! Just quoting results of another website with big traffic Wallpapers.com in 2002-Sept: MS IE 4.x 1.52%, MS IE 5.x+6.x 95.67%, NS 4.x 0.95%, NS 6.x 1.07% Similar results, stronger MS influence, than on my small site. I think Mozilla should not break the traditions, but better to support it. Otherwise Netscape (and so Mozilla) will lose that small portion of the market what still have. Please, do not misunderstand me! I like Mozilla very much! It is getting more & more user friendly and I like that! But I HATE, when I'm forced by anybody to change the tradition what was "standard" for the web for years! And I will protest not to change these traditions suddenly, while about 91-96% of the browser market supports the ALT tooltip! Best regards, Webmaster33
> Following users can NOT view ALT tooltips (because of Mozilla/Gecko engine): > NS 6.x+ (1.43%), Opera 6.x (3.93%) = Overall (5.36%) Whoa. Opera6 uses the Gecko engine? Who woulda thought.... So what you're saying is that current versions of all browsers you tested except IE do not support ALT tooltips. Shouldn't that tell you something? (I'm not even going to go into how unreliable any numbers like the ones you cite are -- the standard deviation of the observations is comparable in size to most of the observations.)
>> Following users can NOT view ALT tooltips (because of Mozilla/Gecko engine): >Whoa. Opera6 uses the Gecko engine? Who woulda thought.... Eh. Nope. It was just a typo. Opera is only listed, because it does not display ALT tooltips, but TITLE tooltips. Opera6 does NOT use Gecko engine. Sorry. >current versions of all browsers you tested except IE do not support ALT >tooltips. Shouldn't that tell you something? IE has about 90-95% in the market. And Netscape 4.x created a tradition, what IE followed, and millions of websites use, including the IE websites. That means, millions websites use the ALT as tooltip, and if the support is removed suddenly, it causes extra work for thousands of people! Do not you think that means something? Comparing to few hour work of a developer to implement support of the ALT tooltip. This is just a matter of principle for the Mozilla developers, isn't it? (and not because it needs so much work on it...) Best regards, Webmaster33
> Comparing to few hour work of a developer to implement support > of the ALT tooltip. This is just a matter of principle for the > Mozilla developers, isn't it? (and not because it needs so > much work on it...) It's been stated several times in this thread that this is not a matter of coding, it's a matter of principle. A principle which I adhere to. I don't think any of the developers here are hiding this; and I don't think any of the developers have a problem with using the Mozilla codebase to promote strandards compilance. Afterall this is a change from the standard policy of some other bodies of promoting deviation from standards using some platform (hint: IE, old Netscape...) :) Sorry, but it's too much noise for too little; stating that you would not duplicate ALTs into TITLEs because of size concerns... well that's just plain crazy. You are willing to change your site (so the "extra work" argument does not apply to your case) but you're concerned about size issues; well, guess what, then why don't you go fight against the use of Dreaweaver-like editors because they create bloated HTML? Afterall bloat is what causes most of the size issues with HTML nowerdays and poor support and implementation for CSS.
This is far out! I added the title thing and was happy it was over. The majority of pages lack it. A minority of use need it. A principal of accessibility for all (e.g. vision impaired) would require it. Cases of axiomatic principle structure (from bill of rights to being given ticket for jay walking) facing demoncracy (pun intended) and raw majority rule abound. But the minority will get what it wants and requires for reason's of principle only when the majority thinks that the principle fits in the axiomatic structure (e.g. all those court rulings that say "society is ready to accept"). So gay weddings to w3c to medical pot smokers are all in the same bag: constrained to sell their principle to the tirannic majority. Think marketing!
> - Until the Mozilla developers will deny implementing ALT tooltip: >[...] > b) I will slowly stop using Mozilla you are free to use any browser you choose, we're not forcing you to use mozilla. if you like msie better, go use it.
Put a note on your website stating that (a) you're too lazy to read the HTML spec, (b) you slavishly follow the erroneous trends set by bad web page editors and other sites' code that you've cribbed from, (c) despite the fact that you're too proud/arrogant to fix it properly Netscape/Mozilla/Phoenix users can get round the problem, which is theirs for chosing standards-compliant browsers (naughty people!), by installing popupupalt.xpi on top of Netscape 7/Mozilla/Phoenix (see note 117 above). Please get this clearly in your head once and for all. The ALT tag is for text to display where the browser cannot display the image. The TITLE tag is for tooltips.
Oops, too many "up"s. popupalt.xpi from http://www.cc-net.or.jp/~piro/xul/_popupalt.en.html
Mozilla users can now view alt texts in the image properties (Bug 101910) in addition to using a scriptlet or personal proxy.
If Opera doesn't show tooltips for alt attributes either, that makes three totally separate browsers so far. (Opera, Konqueror, and Mozilla.)
for Comment #165: >Sorry, but it's too much noise for too little; Not really, if you keep in mind that it affects millions of websites. And not just the sites & the authors, but the visitors, too! This means, Mozilla can not be used for an old site, but user MUST use IE or Netscape v4.x to display website correctly. What is the reason, that there are about the same number of NS4.x users, like NS6.x+??? (think about it) It seems, you forget these facts above... >stating that you would not duplicate ALTs into TITLEs because of size >concerns... well that's just plain crazy. It was just one reason. But mainly I take the stand in this case for those millions websites, what will be not changed and for those users who visit these sites with Mozilla, Opera 6.x, NS6.x, but are FORCED to change to IE or NS4.x. Again a thing what helps Microsoft, just because the matter of principle of Mozilla developers, to NOT keep traditional compatibility with old browsers... Eh... Old browser compatibility for ALT tooltips could be easily supported this way: - if we have ALT attrib & TITLE attrib => display TITLE attrib text as tooltip - if we have only ALT attrib => display ALT attrib text as tooltip & when image display is disabled in browser - if we have only TITLE attrib => always display TITLE attrib text as tooltip Mozilla developers should definitely add this to the quirk mode. Again. Most of you miss the most important thing I mentioned: this change affects millions of websites, which can be only viewed correctly (I mean the ALT tooltips) with IE or NS4.x. for Comment #168, Phil Randal: I can change ALT in my website, if I really want. But I bother about those millions of websites, which does use ALT actively and likely will *never* changed. I'm also here as web user, not just as web author! I'm protesting in name of web users, who does not know why their browser is NOT displaying the important/useful tooltip info on visited sites! They are not understanding the reason what Mozilla developers say about the standards. The users just want to view the new & old websites with the same browser. And they are forced to change back to IE or NS4.x :-((( Not a lookahead thinking style from Mozilla developers!!! >by installing popupupalt.xpi on top of Netscape/Mozilla/Phoenix What do you think, how many users knows about that update? Better would be an option in Preferences, to be able to turn the ALT tooltip traditional feature on/off. for Comment #170, CT: >Mozilla users can now view alt texts in the image properties This is better a bit. But think about, which is easier? Click 2 times (right-click+Properties), or just move the mouse over the image and get displayed the tooltip, so you get the info quicky! I'm sure your answer will be the second... for Comment #171, Ian 'Hixie' Hickson: You forget that Opera, Konqueror, and Mozilla are just about 1-2% of the browser market! This can not be called a major part of the browser market... This percent would not qualify them to throw away a 4-5 year tradition (even if it was not good tradition), which affects millions of websites. These browsers should provide traditional features for a temporary time, which would allow users and web authors to change their behaviours. In that temporary time, Mozilla developers should warn the website authors recommend them to change their website, and leave them time to do the changes. I'm also Perl programmer. Perl has several obsolete features, which are still available for backward compatibility reasons. Mozilla should threat this question similarly. Should provide compatibility mode (quirk mode) to match traditions like this, while publishing for the authors that ALT as tooltip usage is obsolete, and should not be used anymore. But stopping the support of a traditional feature suddenly, is a thing what I can not accept neither as web author, neither as web user!!! You should mark this bug with keyword "compat", and still support this misuse of ALT attribute in Mozilla compatibility mode (quirk mode) temporarily for at least 1-2 years. Best regards, Webmaster33
Seeing as repetition doesn't seem to be an issue... "The alt attribute specifies alternate text that is rendered when the image cannot be displayed." Similarly, we - or even obsolete browsers - don't show tooltips for alternate content in OBJECTs when the original content can be displayed. ALT shouldn't be used for tooltips now, and it shouldn't have been used for tooltips then. > This means, Mozilla can not be used for an old site, > but user MUST use IE or Netscape v4.x to display > website correctly. I have yet to see any examples of old, non-updateable, visible websites that are completely unusable because ALT text is not displayed in a tooltip. If there really were millions, it would have been relatively easy to come up with an example. Regardless, they would still be evangelism bugs. This is simply not a bug with Mozilla. Hence the resolution.
>This is simply not a bug with Mozilla. Hence the resolution. It is NOT bug. It is a kind of obsolete, but traditional feature, what Mozilla should not stop supporting suddenly. Should at least support optionally, which can be turned on/off in the browser.
Agreed why not just give us a pref for this and stop any more arguments
That's beend discussed to death too, both in this bug and in the bug that was specifically about the pref. Feel free to read those arguments in a circle a few times if you're so bored.
The most reasonable argument for allowing this old usage appears to be that old (<= 3.2) HTML didn't have a TITLE tag, so ALT was conventionally used for that purpose. It seems likely that old pages will not be updated, but quite reasonable that writers of new pages should follow the standards, so why not treat ALT as if it were both ALT and TITLE so long as doctype is 3.2 or prior? Isn't that what doctype is for?
I absolutely aggree with reason of Comment #177 From Craig. Clean & well-founded opinion.
I'm impressed so much people thinks this is a bug. Maybe they should be more worried by the general fact that mozilla supports the standards better than any browser. Hey, file this as a bug too. The compromise of the developers in favor of the standards makes mozilla a great and fantastic browser. As a web developer I think this is not a bug, but a bug in other browsers. Go file bugs against them should be the right thing.
<spam> Mozilla has a "quirks mode", where it recognizes pages that do not comply to recent standards and renders them in a way which is bug-for-bug compatible with the old, broken browsers that this old, broken HTML was written for. Rendering ALT as TITLE as suggested in #177 would be continuing this design. </spam>
> renders them in a way which is bug-for-bug compatible Boy did you miss the point! In quirks mode we implement a _few_ quirks that are required to no _completely_ screw up rendering of _most_ sites out there. In no way, shape, or form does this qualify... If we were trying to be bug-for-bug compatible with NS4/IE we would be spending our time doing nothing but that, for one simple reason -- Mozilla was designed as a CSS browser and those browsers' layout models were designed before CSS really existed; hence there are many things in there that would have to be somehow specially hacked into the overal CSS layout engine of Mozilla.
for Comment #180 From Mike Schiraldi: >Mozilla has a "quirks mode", where it recognizes pages that do not comply >to recent standards and renders them ... compatible with the old, >broken browsers. Yes, I absolutely aggree! The "quirks mode" should be exactly for this case. Especially when so much (maybe millions) of websites are affected. for Comment #181 From Boris Zbarsky: >In quirks mode we implement a _few_ quirks that are required to >no _completely_ screw up rendering of _most_ sites out there. Khm. Well then, please answer & explain me: 1) How would *affect most sites*, if this feature (I assume as traditional feature, not a bug) would be implemented & supported by Mozilla? 2) Would this _completely_ screw up rendering of _most_ sites out there? 3) How many sites would affect? (few or much or very much?) 4) How many sites would affect in a bad way, by destroying the lookout of them, if you would implement this feature? (few or much or very much?) I just want correct answers for my questions. Let me see more clear! Thanks, Webmaster33
You completely misread my statement. Again. Say the standards require some behavior X. If behavior X completely screw up most sites, we will deviate from behavior X in quirks mode. Showing tooltips for title instead of alt does not fall into the category of behaviors worth deviating from. So it's not a matter of "if we implement this, how many sites will be adversely affected", but of "if we leave things standards-compliant, how many sites become unusable?". The answer is, "not very many".
for Comment #183 From Boris Zbarsky: >If behavior X completely screw up most sites, we will deviate from >behavior X in quirks mode. Showing tooltips for title instead of >alt does not fall into the category of behaviors worth deviating from. Thanks your answer. Of course, not displaying tooltips will NOT screw up sites. But will make those informations unreachable/unavailable, what was intended to be shown as tooltips. (you may say, user can use properties... Eh, it is unusable for this task. You can not click 2x for each small image on the page...) I do not aggree your opinion, that this is just a small feature, which does not worth to deviate from your usual behavior how you currently add a feature to quirks mode. You forget/disregard the fact, that it IS TRADITIONAL FEATURE, what was used for several years as standard feature to display tooltips! This is a well-founded reason, good enough to support ALT tooltips in the quirks mode. >"if we leave things standards-compliant, how many sites become unusable?". >The answer is, "not very many". I do not aggree. There are STILL a lot of websites, where you could find ALT texts on the website (and unfortunately not to support the visual impaired visitors, but to display additional info as tooltip. IMHO the text used for tooltip also helps visual impaired visitors, too.) The ALT tooltip informations actually are viewable by most of the visitors, since they use MS IE. They may want to switch to Mozilla, but they see, tooltips are not displayed on most websites. So they change back to IE, because they say, Mozilla is sh*t. I know, this is not true, but most users will say that. And Mozilla will be not able to increase its share on the browser market. Mozilla developers will lose a lot potential users, with their obstinate behavior, by sticking to the standards, and denying to implement a feature which is known widely by the public as TRADITIONAL feature. You should support it for a temporary time (e.g. until 2004.dec.31). The motto is: "Mozilla: SUPPORT THE TRADITIONAL FEATURES!" Best regards, Webmaster33
2005.jan.01 you'd have someone saying he's been always using alt for tooltips and now you're breaking his pages. We shouldn't encourage bad web design in this way. See http://bugzilla.mozilla.org/show_bug.cgi?id=25537#c133 for an easy way to fix it.
The folks at Netscape are idiots. Forgot standards and face reality. Web pages stopped working correctly starting with Netscape 6.0 because of the refusal to support "alt". It doesn't matter, our web apps became IE specific long ago, coding for Netscape is a waste of time with 98% of our visitors using IE.
What exactly does Netscape have to do with this?
Maybe nothing. I know little about what I speak. I am merely venting frustration at how alt attributes on hundreds of my web pages stopped working with Netscape version 6.0 and above. Then I find this site where the excuse is made it was done because using alt for tooltips is not part of the w3 standard and how they know it will break pages but it must be done. Sounds like self righteous bullcrap to me. Millions of web pages broken, once the cat is that far out of the bag, it's time to change the standard, not old pages.
> I am merely venting frustration at how alt attributes on hundreds of my web > pages stopped working with Netscape version 6.0 and above. You're looking for Netscape's feedback site then: http://channels.netscape.com/ns/browsers/7/feedback/default.jsp Bugzilla is only for reporting bugs in Mozilla. Netscape can add whatever they want (standard or non-standard) to their suite implementation, and on many occasions they have. However, I wouldn't hold up much hope of even Netscape deciding to display ALT tags as tooltips. > how they know it will break pages but it must be done No, it won't break pages. Pages will still load and layout will be the same whether or not ALT tags are displayed as tooltips. We do know that it will break certain developers' view of the use of ALT tags, but that's not the Mozilla project's problem. The content of TITLE is displayed as a tooltip. If you're still actively developing, use that. It's standard and cross-browser compatible.
Comment #189 From Marcus Campbell >It's standard and cross-browser compatible. NO. TITLE is not cross-browser compatible. Only browsers 5.x, 6.x understand TITLE attribute. Check Comment #162 for some info & some of my stats.
I said cross-browser compatible. Which it is. Current, and recent, versions of Mozilla, Netscape, Internet Explorer and Opera, amongst others, all support the display of TITLE attributes as tooltips. Note also that Mozilla is neither a 5.* nor 6.* versioned browser. Netscape 4 came out in 1997 before Netscape 6 in 2000, and IE4 in 1997 before IE5 in 1999. NS4/IE4 were obsoleted after 3/2 years. It's been 2/3 years since TITLE has been supported in the main browsers and - although "lies, damn lies and statistics" - over 95% of users are estimated to be using a browser that supports it. As you pointed out. HTML 2.0 (1995): "ALT - text to use in place of the referenced image resource". HTML 4.0 (1998): "Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object)." (Included since the first WD the year before.) How many years do developers need to learn a markup language? --- The QA originally marked this bug as INVALID in comment #3. See comment #143.
Component: Layout → Layout: Tables
Ok guys, I think this bug is becoming a discussion forum rather than a place to file and resolve bugs. How about we just take a vote between people wanting to do support alt as tooltips and people against it. Then we take the decision based on the results. After all if Mozilla is a community browser first and then a standards compliant browser, we do what the community wants. We can put up a voting place in mozilla.org where people vote for what they want. Personally, since I am not a web designer nor do I browse many funky web sites, I do not care either way. I just think that the mozilla developers should heed to the the user community demands more than the standards, if there is a conflict. My $0.02 worth..... Jalpesh.
Sorry, Mozilla development is not a democracy. It's a meritocracy.
Component: Layout: Tables → Layout
Shut up
*** Bug 177061 has been marked as a duplicate of this bug. ***
*** Bug 177347 has been marked as a duplicate of this bug. ***
I agree, this bug is becomming a discussion forum. But since it is, I'll add MY four ha'pennies, ;) and just say that it seems to me that if NS4 and IE both supported alt-tooltipping when HTML 3.2 was standard, then it was in effect standard, too, so I agree with comment 177 in thinking that it should be supported if and only if the page has a doctype declaration of HTML 3.2 or earlier. Not that it'll change anything, having read all 196 previous comments I think it'd be easier to get an email through to the president telling him to fix the instance of it on the whitehouse.gov page than to convince the Mozilla programmers to support it. :-P
*** Bug 178121 has been marked as a duplicate of this bug. ***
*** Bug 181771 has been marked as a duplicate of this bug. ***
Well if the following does not convinse you then nothing will. Here is a time when having alt text displayed as tooltip is 100% logical and makes perfect sense using the specs: Sometimes I have to view pages written in languages that I don't know. I can use an automated translation service to change the text of the page. Unfortunatly it cannot translate the text in images. it can translate the alt and title text though. unfortunalty not being able to read the immage in the first place the title attribute is worthless to me as it is for auxillery information. The alt text though is perfect, as the text in it should exactly match the text in the immage. So I NEED to see the alt text. You may say that i should just disable the immages. well if that is the case how could i see the immages of the products displayed on the page? so if you are not even willing to put it in the quirks mode then this otherwise perfect browser is a pice of junk!
Webmaster33: > ---------------------------------------- > Following users CAN view TITLE tooltips: > MS IE 5.x+6.x (88.61%), NS 6.x+ (1.43%), Opera 6.x (3.93%) = Overall (93.97%) > > Following users CAN view ALT tooltips: > MS IE 5.x+6.x (88.61%), NS 4.x (2.12%), Opera 5.x (0.49%) = Overall (91.22%) > > Following users can NOT view TITLE tooltips: > NS 4.x (2.12%), MS IE 3.x, 4.x (3.22%), Lynx (0.2%) = Overall (5.54%) > > Following users can NOT view ALT tooltips (because of Mozilla/Gecko engine): > NS 6.x+ (1.43%), Opera 6.x (3.93%) = Overall (5.36%) Notice that the amount that can't view TITLE tooltips is very small. I think this is the proper place for a little lecture on the need for occasionally breaking backwards-compatibility. In the world today, companies/users pressure hardware and software developers to keep things backwards-compatible. The reason people do this is because they don't want to invest the money into upgrading their systems. Since all the new browsers support TITLE tooltips, all people have to do is upgrade their software. If we made everything backwards compatible forever, the cost of producing new technologies would become overwhelming. For instance, serial and parallel ports are going to be removed from the chipsets of new PCs. This will be a dilemma for people (for instance scientists) using devices that require parallel port, but won't be a major issue for most people as most devices nowadays are USB and Firewire. If they have antiquated devices, they can place a card in that gives them these ports, but its a waste of resources to place this on new computers. What if all computers nowadays still had AT plugs for keyboards. Do people really need this? Backwards compatibility has led to many many problems. Microsoft software is a prime example of where backwards compatibility has gone bad and they are caught in a rut. They can't make significant changes to their systems without angering many users. There comes a time where you just have to say, "No more!". Mozilla/Netscape 6+ is a significant rewirite of the code, and it is understandable that we would want to follow the standards. As the number of Netscape 6+ users goes up (and its more likely to continue going up than go down), web developers will be more and more pressured to stop ignoring it and follow standards. I started web developing around the time I started programming C++ (back when I was 15 - in 1995). I'd have to say that even though the standards can be a bitch at times, its much better than web languages being a free-for-all. We don't support document.all, layers, and many other non-standard items either. We also support some non-standard IE items and we support it even better in most cases. If we did this, it was because we saw a reason for it. innerHTML was because the standards don't at the moment have anything comparable. Shortcut icons are because this is a feature that gives sites the ability to show their individualism along with making bookmarks easier to differentiate. I'm sorry the changing ALT parameters to TITLE tooltips is an inconvenience for you, but since only 7% of your users will be left to the dogs (assuming they even care about tooltips), it sounds like the makings of a rather good satisfaction rating. You can provide info on your site on what users can do if they are thwarted by this. In terms of work, all you have to do is run your site through a perl script assuming you don't use templates which would make it even easier. If this is not sufficient, it is something to bring up with w3c. The web languages evolve and webmasters should be aware of such. unknown: There is only one solution we could provide, and that's the ability to toggle the behavior. This would be helpful for unknown's translating issue, but not for a webmaster as users are not likely to do so on a site-by-site basis. Of course, http://bugzilla.mozilla.org/show_bug.cgi?id=25537#c133 provides that solution and although the average user wouldn't know about it... i'm sure this can be made as a default bookmark or such. In conclusion: Unless the standard changes, this bug will not be fixed. No amount of complaining, bickering, name calling, or crying will change that. We might offer a workaround, but by default we will only display TITLE as tooltips. Period. We care about our users, and this is not out of laziness. We just are following what we have always followed since the major rewrite of Netscape that later became the Mozilla project, and that is that we don't want a repeat of the days where you had to write almost totally different pages for different browsers. Since we are compatible with all the newer version browsers (IE6, Opera6, etc) this is moot. That is all we are aiming for. If people don't like that, they can upgrade their browsers. If they can't support the browsers due to poor hardware, that's not our fault and I doubt they would be able to run too many other applications either. I'm sorry about that, but there is nothing we can do. There are browsers out there that use the gecko rendering engine without most the features of Mozilla so its not as memory- intensive. The small amount of people that can't run Mozilla can use those instead. As time goes on, less and less people will be using older browsers so this issue will fade away. Please, no more comments except for ones that are of a development nature.
unknown: An image with text in it on a page being translated will not be an issue if the page is done properly... Let's say an image that says, "Here is a gecko" and shows a picture of a gecko. The parameters should be: ALT="Picture of a gecko" TITLE="Here is a gecko. He's cute and green, and masters the Vanderwaals force for running on any angled surface" Therefore, TITLE will be translated and shown as a tooltip... if the web developers did it correctly... Who's lazy? --- Web developers: Just write a perl script to bulk modify your pages, and you are all set. You can even provide a link at the bottom of your page that switches title with url for older browsers. WE should not be doing your work for you. WE do not write the standards alone, and Microsoft was involved along with a good amount of other people who put a lot of time into making the standards better. They will take a little getting used to, but if we can write a browser based on them, you can use them in daily practice...
BTW, when I said lazy... I wasn't inferring all web developers are lazy... I was just pointing to the fact that it just appears some web developers are complaining to us because they would rather we change our code and open a pandora's box than they have to fix their pages to follow the standards. What will we have to break in the standards two years from now if we set a precedence of this?
For reference : Comment #73 , comment #83 , comment #117 ( URL is now : http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en ) and comment #133 .. .. offers WORKAROUNDS. Use them if a standardscompliant browser is not your thing. But do not grieve over this in this bug. It is and will stay WONTFIX
Daniel: heheh... Sorry to be offtopic, but I had to respond to a comment I got a kick out of. After skimming your comment #166 a few times (equal to reading it once ;-) I would have to agree with you. I personally don't have anything against gay weddings, nor weddings of more than two people, nor medical pot smokers, and assisted suicide (with proper non-system-abuse) measures put in. Of course, those issues really bring forth the question: Why don't people just mind their own business. If some guy wants to marry nine women and two men, he should be able to and its none of our business. This is a bit different because the web development community can't really mind their own business because they are affected by it. Its more like the government changing the speed limit on highways to be in kilometers per hour. Still, people can adopt and the government has every right to convert us to the metric system and people can bitch and moan but there are good reasons behind it (think about the lost martian probe due to conversion issues). There are good reasons behind this too, and although the transition is difficult for people, they will get through it and I doubt it will cause World War III.
This is a place where everyone can say some words pro and contra alt tooltips and where we can read why this bug will never be fixed. Do you really beleive that it has any chance to be fixed? I know that we are removing features instead of adding comfortable ones. And if 2 or 6 men think that some feature is useless or harmful, it will be removed, even when 100 or 10000 men find it useful or 1000000 webmasters will have to totally rebuild pages or scripts. Thank you.
the workaround installation plugin works nicely. Else, if you really want to have ALT tags show up as tooltips in YOUR Mozilla, then program it and compile your own build....WOOHOOO. It works nicely, even more so without a "workaround" or a plugin. Keep it lively.
*** Bug 184489 has been marked as a duplicate of this bug. ***
I have only just come across this "feature" of Mozilla. The only thing I want to add is that with the alt statement the text can be formatted using standard escape characters (e.g. \t for tab and \n for new line). The title statement does not honour those escape characters so the data come out as a single stream of data. So how does this help the user if the alt statement has to be replaced with the title statement?
Uh, there is nothing about the alt attribute that makes it formattable when a title attribute is not. If alt attributes were to be shown as a tooltip, they would use exactly the same code as title attributes.
Doug: From comment 209 Finally, a comment that actually adds useful information. > I have only just come across this "feature" of Mozilla. The only thing I > want to add is that with the alt statement the text can be formatted using > standard escape characters (e.g. \t for tab and \n for new line). The title > statement does not honour those escape characters so the data come out as a > single stream of data. So how does this help the user if the alt statement > has to be replaced with the title statement? Can you please list when you've seen these formatting characters actually work in either ALT or TITLE? I don't know if that is part of the standard. I'll have to look. http://www.w3.org/TR/html4/struct/objects.html#edef-IMG http://www.w3.org/TR/html4/struct/global.html#adef-title http://www.w3.org/TR/html4/struct/objects.html#adef-alt http://www.w3.org/TR/html4/types.html#type-text They both use text 6.3 Text strings A number of attributes ( %Text; in the DTD) take text that is meant to be "human readable". For introductory information about attributes, please consult the tutorial discussion of attributes. http://www.w3.org/TR/html4/sgml/dtd.html#Text <!ENTITY % Text "CDATA"> http://www.w3.org/TR/html4/types.html#type-cdata Notice, it says: Ignore line feeds, Replace each carriage return or tab with a single space.
URL: http://www.w3.org/TR/html4/struct/obj...
Attached file For Doug comment 209 —
Test this out in Mozilla/IE. Note that neither escape /n or /t but notice that IE does escape &#10; and &#9; and Mozilla doesn't. Which is correct?
According to: "Replace character entities with characters" in: http://www.w3.org/TR/html4/types.html#type-cdata Mozilla should be replacing &#10; with a new line and &#9; with a tab. Good catch Doug (If this is correct)
brian/doug, that is COMPLETELY UNRELATED to this bug, which is wontfix. please discuss that in another, new bug. thanks.
The bug is bug 67127. Problems handling whitespace characters in tooltips are well-known. (See also bug 47078.)
Thanks Christopher... I was hoping someone knew a bug # for that (assuming it had already been filed).
*** Bug 186322 has been marked as a duplicate of this bug. ***
How often would the contents of ALT and TITLE actually be different? Probably not too often when you think about it (I know when I built my webpages a few years ago with NS4.5's composer I selected ALT tags that would be appropriate in both Lynx and as NS tooltips). So in effect, what we are asking is that billions of websites go about and *duplicate* (not replace) the contents of ALT tags because if they replaced them then all those Lynx users whom we're all so worried about would be out of luck. Not only would this be a collosal waste of time and effort but it would also unnecessarily increase the size of webpages, slowing rendering, etc., etc. I see nothing that actually forbids the display of ALT as a tooltip, and those sites that seriously do abuse ALT are generally picture galleries that no Lynx user would be visiting anyway. Finally, not even Mozilla Composer supports or rather encourages the use of the TITLE tag in the image insertion dialog, making this entire Standards Compliance debate ring rather hollow - I didn't even know TITLE existed and started wondering why my tooltips weren't displaying even though I was using Mozilla Composer to build webpages. At least if Moz Composer had a TITLE field in the image insertion dialog I might have been able to figure out what was going on, but no. At any rate, knowing better I now use the tooltips extension and I am slowly but wastefully duplicating (not replacing - duplicating) the ALT tags to TITLE tags on all my images.
In almost all cases, if the alt and title attributes have the same value, the alt attribute is incorrect.
David: What we are asking is that web pages follow the standards so they are rendered properly. Its not our job to do that for them, and its not our fault they wrote them incorrectly. The only thing I see as a possibility is displaying ALT as a tooltip in quirks mode when the image URL is invalid and displaying ALT as a tooltip in standards mode when there is no title attribute. I think we can make a concession for people who wrote pages in that manner before the standards were so concrete.
*** Bug 187407 has been marked as a duplicate of this bug. ***
*** Bug 187657 has been marked as a duplicate of this bug. ***
Just an idea... Why not have a menu option to remove the images or even a selected image and reveal the ALT text in situ ? Currently it is possible to stop receiving images altogether but it is not posible to 'reveal ALT text' for a current page. I know that this is not a tooltip solution but IT IS standards compliant ! and if it were suspected that there was unseen information in ALT texts then a context menu option to reveal the text instead of an image would be a work around. Another solution might be on selecting the 'Reveal ALT text' context menu option that the image ALT texts are displayed in small yellow bars over the top of the images sort of like pseudo tooltips. Just an idea !
101355.471@compuserve.com : You can write a bookmarklet for that.
*** Bug 187883 has been marked as a duplicate of this bug. ***
Not sure what a 'bookmarklet' is ! but no doubt you could, but wouldn't it be much simpler to right click on a page and select "Show ALT text" to reveal the ALT texts just for that page (or may be from then on until "Hide ALT text" is selected) ? I believe that to show ALT texts in a pseudo tooltip sounds pretty good and wouldn't require a standards breach.
101355.471@compuserve.com: Not a good idea to have right click solution "Show ALT text" to show the ALT texts as tooltips for the page. Right click menu may contain often used features only. I think an option in Preferences would be the solution. I describe it below. Mozilla developers: The problem is, that if millions of potential users (potential, because they currently use IE) would download, install and use Mozilla, after a few weeks many of them will ask: "Why we do NOT see the tooltips on several sites? We NEED tooltips on all websites!" They do not know, nor about standards, nor about the ALT/TITLE attributes! They even do not bother about them! They WANT, what they THINK IS the standard. The tooltips was TRADITIONALLY displayed through the ALT tag. And the following browsers CAN display ALT attribute as tooltips: MS IE 5.x+6.x (88.61%), NS 4.x (2.12%), Opera 5.x (0.49%) (the percent may vary but mainly shows the proportion) Users will then say: "We will better use the IE 5.x & 6.x, which supports the STANDARDS, and TRADITIONAL features..." They will not bother, that Mozilla or Netscape developers say: "We support the standards, the webpages are wrong!". Users will laugh... And use IE, which displays all websites "correctly" with tooltips... Ladies and Gentlemen, Developers, that's the situation... Here are my suggestions, which may help to make both group satify (standards & tradition group)... Solutions: 1) As I already suggested, Mozilla developers should add this feature to the quirks mode, to maintain a traditional compatibility for ALT tooltips, in the following way: - if we have ALT attrib & TITLE attrib => display TITLE attrib text as tooltip - if we have only ALT attrib => display ALT attrib text as tooltip - if we have only TITLE attrib => display TITLE attrib text as tooltip 2) Add a config option in Preferences/Navigator. - Option name: "Traditional feature: ALT display as tooltip" - Option type: Checkbox - Option default: Checked (or unchecked, if you really want this) - Rendering: as described in solution 1). This way anybody could disable that traditional feature, especially those who does not want it. That would be a fair solution, and would satisfy both group (those who want ALT as tooltip, and those who don't). Please, please, please consider implementing this suggestion, as this would make a lot Mozilla users happy... Best regards, Webmaster33 P.S. Users, please vote to have this feature implemented
I didn't mean actual tootips, but rather a display of the ALT text that looks like a tootip. I.e. rather than remove the image and show the text in its place display the text in a bar over the image, but not as a real tooltip. When used as ALT is intended the default font size for the ALT text is often to large to display the entire text in the 'image box' area when the image is small anyway. So why not reduce it and display it so it looks like a tooltip on top on the image in question.
*** Bug 189160 has been marked as a duplicate of this bug. ***
*** Bug 189376 has been marked as a duplicate of this bug. ***
First of all, my proposed solution: If the ALT tags showed an ugly green "ballon help", and the TITLE tag displayed "ballon help" with a white background, and in the event of both ALT and TITLE there would be white-bg'ed baloon help under the mouse curosr and an ugly green "ballon help" under the white baloon help, then ALT tags would look different than TITLE tags, people could see that there is a difference (and would lean towards preferring the prettier TITLE tag), and those with huge compatibility concerns could be satisfied because ALT texts could actually be seen, and those who aren't in the know wouldn't assume that there is a bug the way many do now from the apparent complete non-support. This seems to solve everyone's primary goals, and such an alternative is kinda what comment #223 was getting at: Most of the Pro-Alt-Tooltips people don't care if it looks like a standard Tooltip, just that the information isn't fully, totally ignored. Now that that's out of the way, onward with the responses: (I apologize in advance here for my sloppiness in handling white space in this post.) The standards pushers are being consistant with their arguments, but I feel they are overlooking some major points: #1: The question at the beginning of comment 94 is properly answered "No". As comment 95 says: "There is no mention there about ALT not being used as tooltips, but there is about title being used as tooltips." The tooltips discussion is used solely as an example, though. Nowhere in the standard does it say that hovering over an image absolutely may not display the ALTernate text. As a web content creator and somebody with strong beliefs in backwards compatibility, including old text-mode browsers such as Lynx, I have great respect for making ALT tags for their proper use. If I write values for ALT tags, I'm not going to make web pages less accessible by giving a detailed description which can't be understood without seeing the image. I'm going to actually describe the image. To me, using tooltips as a serious method of gaining more information seems silly, and so I'm likely to never make use of the TITLE tag. If I am making ALT tags, my intention is to provide a better web experience for non-graphical browsers. However, there's also an issue of what my time is worth. I am sometimes willing to take the time to fill in ALT tags. When I do, I have entered into the habit while checking my results of using mouse hovering (tooltip-checking) to verify that the ALT tag is appropriate to the image it is by. (By doing this checking, I have sometimes caught errors where I described one image when I thought I was describing a different image.) It's just not a big deal to me, but since hovering is so simple, I may check it and I'll certainly fix an error if I see I made an error. However, running a different browser, like Lynx, is just way TMW (too much work) just to check the low priority ALT tags. Assuming there are more like me, this in fact flies in the face of the arguments that showing the ALT tags tooltips will make the web worse for non-graphical browsers. By removing the hover check and NOT providing an alternative ALT-viewing technique, the increased effort requirements will actually drive developers away from deciding to care about non-graphical users. I therefore totally dispute the claims of the popular Comment #1 ("This encourages people to use ALT attributes for tooltips, which is wrong."), Comment #148 ("alt text as tooltip discourages authors from writing proper alternative text"), and re-iterated by Comment #73, point #2, subcomment #1 ("people will continue to write bad code.") Not supporting ALT heavily encourages ALT to be disbanded totally, and THAT shall cause the happening of Comment #31's statement: "people will be discouraged from using them for their correct purpose." It seems the best solution for a webmaster available now, short of using both ALT and duplicate TITLE tags, is to use ALT tags and use the JavaScript from comment 133. This will work in all tooltip-supporting versions of MS IE and Netscape 4, and the only thing it won't tooltip in are the Mozilla/Netscape6+ users who have disabled JavaScript. Although I'd generally suggest choosing to abandon Netscape 4 rather than hurting users of Mozilla, given such an unpleasant choice, the truth is that in this case most users of newer browsers who have disabled JavaScript know how to turn it back on while users of NS4 in university computers may not have quite as much of a choice. So, if making additional text and then checking for them in a graphical browser, the ALT attribute seems to be the better choice. Not to mention that ALT tags work in older browsers, such as early versions of Lynx that don't support the TITLE attribute. (It's really ironic that the ALT-tooltips opposition frequently mention support for this sort of browser when they are actually HURTING one and probably helping zero.) The real best option may be to use duplicate ALT and TITLE attributes in HTML without requiring JavaScript to duplicate the job. However, when quickly coding in notepad and wanting to get through the image reference ASAP before my epiphany of creative thoughts gets too sidetracked, it is sometimes just TMW to do bother typing ALT="something appropriate". It is certainly too much work to be duplicating that effort in TITLE attributes. The author of comment #56 agrees. Besides that, it seems like it should be unnecessary: Comment #30 calls it bad design and Comment #51 is quite right when saying "Quite frankly, it is a waste of bandwidth to have to put the same text in both a title and an alt attribute." Comment #160 point #4 says the same. As ALT is used for temporary rendering before an image is loaded, it is still good practice to use them for Mozilla browsers even without the additional argument that non-graphical browsers could enjoy them. However, when viewing pages with broadband or locally, the images (especially those below the first screen) may be loaded so quickly that there's not a good chance to see the ALT tag within Mozilla. Right-clicking the image and selecting properties is not, as comments #97 and #170 suggest, a valid alternative. For one, it is just more work (if I wanted to do lots of work, I could Alt-Tab to Notepad and carefully check the source), but more importantly, as pointed out in Comment #98, it DOESN'T work! (Tested in Netscape 7.01 for Windows.) Now, tooltips could work if it weren't for the opposition to them. I believe the opposition refusing to implement tooltips oughta provide one of two things: An alternative, or a good reason why it shouldn't be available. I'm not seeing either. The simple truth is: Nowhere is there an argument with substance, that I've seen on this page, demonstrating that it breaks the standards to go ahead and show the tooltip. People argue that it is not necessary to show the tooltips to be standards compliant, which is completely true and not in doubt, but this doesn't show that displaying a tooltip containing an ALT tag is a violation of rules. Comment #137, middle paragraph about the REC, says that it in fact is not a violation of rules. Comment #140 also states this. If the rules don't specify such a thing, then no amount of arguments stating that (1) some people think that the rules should or (2) that people of a certain opinion erroneously believe a lackage of requiring implies a forbiddance of supporting, will be enough opinions to change the facts. If it isn't forbidden, it isn't forbidden. And no, inserting JavaScript isn't a valid solution because people can't do that on web pages that aren't theirs. Besides, a client-side problem should be remedied with a client-side fix, not becoming a web-authoring issue. Making a browser reduced in functionality unless, for every page desired, the user bothers to go to a "Fix Current Page" bookmark containing JavaScript is a ridiculous set of procedures which would be not only inconvenient but also a terrible precedent. A web proxy may technically work, but as Point #4 of comment 73 says, this is unsatisfactory since "the group of users using a rewriting proxy will not be big enough". This includes myself: I for one don't know how to set up a web proxy for viewing pages on my local machine. Just because some server/traffic experts could go through the significant work of installing a web proxy just to fix this issue isn't a decent reason not to include working code in a client which is so simple that a single line of JavaScript can do. (Or a simple if(!alt) alt=title; statement in a real programming language inserted at the correct source line.) Likewise, in regards to Comment #55, learning how to create a seperate distribution named Altzilla and how to keep it current with the latest versions of Netscape's releases is much more work than checking a preferences checkbox. Comment #128 calls it "prohibitive". Maybe the comments #117 and #155 and #169 would be VERY applicable about "Those of you who desperately want alt attributes shown as tooltips in your own presonal builds, btw, should look into the following Mozilla extension", but looks like that site is down. (Hmm, Comment #204... shows up as a blank page. Will have to try in another browser... Ah, there. Now, how to install this thing? Preferences, Advanced, Software Installation, Enabled software installation. Hmm, NS7.01 doesn't have such an option. Grr...) Replies to specific comments: ----------------------------- Comment #143: Netscape says they won't support ALT? Where's this? ----------------------------- Comment #74: "Mozilla is build to evangelise standards, but not acting like a particular" [way] "in order to satisfy users' needs." What about Netscape 6+ users? Maybe the Mozilla dev team that is involved in snapshot releases cares more about certain philosophical beliefs like standards compliance at the cost of everything else, but Netscape's goal is to actually have a useful browser. I was told that bugzilla.mozilla.com is a valid place to look up this Netscape issue. (Hmm, Comment #189 says it isn't. If I knew that before I read 189 comments then maybe I would have brought this up straight to Netscape, and ignore Bugzilla altogether.) So I guess I will be going somewhere else to encourage Netscape to change the unsupportiveness of ALT tooltips which is currently set to plague Mozilla for the foreseeable future, but that doesn't address the logical fallicies of nearly every ALT-tooltip-opposing argument on this page. There is a desire to support users's needs, which is why the DOM's .innerHTML property is copied from MSIE despite it not being a part of W3C recommendations. Using only "pure" code can get the same job done (see http://wsabstract.com/javatutors/dynamiccontent4.shtml which counters Comment 201's claim that innerHTML is necessary) but support for innerHTML was just found to be desirable, so it was allowed in. There's also popular support for the idea of ALT tags to act as the default value for TITLE tags. As comment #96 says, if nothing but the standards is desired, use Amaya 6.1. I've never even bothered downloading Amaya because I shudder at the idea of not supporting anything except what is absolutely required by the standards. ----------------------------- Comment #85: The "alt" attribute is not extra information. It should be exactly the same information as the "src" attribute, but in text form instead of image form. "Exactly"?!? If a picture is worth a thousand words and the average word is at least 5 characters (including a space in between words), then that's 5K worth of text within the ALT attribute! A comment by the same author, in comment #61, says "Tooltips are not equivalent to a secondary rendering of the content." Well, then what are they? When I highlight a graphic with a folder in Microsoft Word, a tooltip pops up telling me what that graphic represents: "Open". Essentially, this tooltip is acting exactly like the contents of the picture, showing Opening. My first exposure to tooltips was actually ALT tags showing up, so the tooltip described the graphic under the mouse. That's exactly what the ALT tag is for: Describing, real basically, what the graphic is (perfect both for those graphics viewers who just don't understand what they're looking at and also those who don't understand the contents of the graphic becaues their graphicless web browser doesn't even show the graphic.) In comment #219: In almost all cases, if the alt and title attributes have the same value, the alt attribute is incorrect. This is highly doubtful. Perhaps one or more real-world examples would back this statement up as well as some others that are made, as well as people lessening their desire for TITLE attributes to copy from ALT when TITLE didn't exist, if people saw why most ALTs were inappropriate texts to be used as TITLEs. Surely the Alt-tooltips proponents, including myself, think that they are definitely appropriate for each other when manually copied, for they even want these things copied more often, automatically so. ----------------------------- Comment #71: If "-----------" as a tooltip is too ugly for you, just move your mouse off of the graphic. The ALT text is meant for non-graphical browsers, and showing it as a tooltip isn't meant for communicating extra information. "---------" is a perfect textual description of a horizontal line. ----------------------------- Comment #141: "I, as *a user*, am sick and tired of seeing stupid tooltips pop up everywhere when browsing with IE." If you don't want to see the tooltip, why are you hovering your mouse over the graphic without clicking? I don't see why you do, and if you do by accident, it shouldn't be too much work to much move the mouse away. "Hover your mouse curser over their logo, and a tooltip will pop up and say "Google". What good does that do?" Sometimes it says something different, like "Happy Martin Luther King Jr. Day" or "Happy Chinese New Year". By hovering in MS IE, I was able to figure out what the special logo for the day meant. Not so in Netscape 7. (And even if these aren't the perfect examples of ALT texts, they aren't so bad that they would seem to screw up any graphicless browser that reads them.) ----------------------------- Comment #14: From the HTML 4.01 spec: "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." In other words, displaying the contents of the "alt" attribute when we've successfully loaded the image is decisively WRONG. This is wrong. The primary purpose of the ALT tags is for graphicless browsers. This doesn't mean other browsers are forbidden to use it: For example, from my reading on this page, Mozilla does use the ALT tags while a graphic is downloading and the sentence before "in other words" doesn't imply there should be any difference, the sentence after those words does. Nowhere is there an argument with substance demonstrating that it is in anyway incorrect to show a tooltip. ----------------------------- Comment #31: Authors who want to use ALT text correctly will remove it when they see that it's causing tooltips (that don't give any additional information once you see the image) to appear in our browser. No, good ALT texts will coincidentally work just fine as tooltips, appropriately describing the contents of the image. There's no reason to get rid of that. ----------------------------- Comment #31: Authors who want tooltips will write ALT text (rather than TITLE text) that is not appropriate for alternate text for the images and will cause pages to appear as nonsense to blind users or users who aren't loading or can't load images Again, conversely, if they make the tooltips appropriately, it works just fine as ALT text. ----------------------------- Comment #40: No longer true, as tested in Netscape 7.01 under Windows. ----------------------------- Comment #139: This is the first argument against ALT tags that makes a conclusion against ALT tags without using back logic or a totally baseless jump to the conclusion based on a leap of faith in the conclusion being lept to. The difference between ALT and LONGDESC isn't just that old browsers supported ALT as tooltips, but that many more people have used ALT. I for one haven't heard of how LONGDESC is supported in anything, and unless I can telnet to my local ISP and run Lynx and see LONGDESCs then I suspect that ALT tags are simply more useful, if for no other reason than for legacy support. Therefore, when checking tags with a mouse hover, I'd like to see ALT. As for BORDER, that has no reason to go into the ALT tag: It's effect is noticable without tooltips needed. (That was kinda the whole point of the attribute.) ----------------------------- Comment #148: You forgot to include the most important issue of them all, namely that displaying alt text as tooltip discourages authors from writing proper alternative text, causing pages to be unusable for blind users. ----------------------------- Comment #161: As far as NS4 is concerned IMHO clearly Netscape has released a better more portable smaller memory footprint browser based on Gecko that supports TITLE and a huge number of other standards as compared to the previous NS4. Therefore NS4 should be considered obsoleted by the newer versions of the browser. Netscape 4 works on a 286-compatible Operating System, Windows 3.1. No version of NS6 does. ----------------------------- Comment #165: He probably does. ----------------------------- Comment #173: Here is a website that uses ALT tags but which cannot be updated: http://web.archive.org/web/20000608132336/www.zhq.com/entry/main.htm ----------------------------- Comment #191: Numerous. This is the one issue in NS6+ that I've bumped into that truely breaks the simplest of HTML rules that worked perfectly well 9 years ago (maybe longer). ----------------------------- Comment #201: See note about error surrounding innerHTML. Since PS/2 keyboards offer nothing new over AT keyboards there's no strong argument why AT keyboards should have been ditched. The reason computers don't have AT keyboards now is because the plugs would be expensive and adapters do exist. That's an issue of economical expense, which is not the reason ALT tooltips aren't supported. 7% of users is an important statistic on commercial sites that don't want to make their site worse for 7% of their visitors. Backwards compatibility causes problems but can save headaches just as well as it can create them, and backwards compatibility should be sought when there is no reason (not even effort requirements) to NOT have backwards compatibility, other than project leader pride (not a moral reason to cause headaches on others). Comment #33 documents how NS4 doesn't support title, as found on some online documentation for the old Netscape versions. As you can see, old browsers continue to have popularity, in part because they work well on older works. It is truely a scary thought that every 4-6 years web standardization committees may have enough power to throw away all the old working coding techniques, meaning that after 30 years I'd have to use 5 different web browsers to visit all my old, no-longer-updating pages stored on www.archive.org (or google's cache, or my read-only CD-R backups, or...) Running a site through a perl script isn't an option on a site without a perl interpretor installed, which the majority of Windows platforms which can be used to display pages (even if not host them), and once again, a perl script on a server doesn't matter since this is primarily a client-side issue, not a real web-authorship problem like some are trying to make it out to be. ----------------------------- #85: That is the philosophy which brought us Tag Soup. Ha. In order to support browsers that don't understand (B)(/B), and to support browsers that don't support CSS, the necessary code is: (FONT style="font-weight:bold")(B) text (/B)(/FONT) The new family of browsers, bent on destroying the simplistic (B) tag understood by anyone who has ever used Microsoft Word, and instead using CSS which has numerous characteristics that unnecessarily make it far less intuitive than necessary, is far more guilty of creating Tag Soup. Of course, this is off-topic, I know. ----------------------------- The one comment I marked to respond to, but didn't find anything to add (after reading enough other material and deciding there'd be no point), is: Comment #47 (1st paragraph): why MS IE won, by copying and adding ----------------------------- I took the time to read messages 31 and 133 multiple times before posting. It'd be nice if the excellent comments in Comment #51 were re-read by some of the opposition to ALT tooltips, keeping in mind also the comment #100. Comment #100: 99,1% of webpages with alt tooltips will never be corrected. I'm very sorry. --2g
Note: if you would like to have the ALT Tooltip added then VOTE! Click the "Vote for this bug" link at the top of page, check the checkbox on the next page and submit. IMHO, additionally to the fact, that we try to convince the Mozilla developers in written form, about that many users would need the ALT tooltip feature (at least in form to have available by default, but turnable off in the Preferences for those who don't want that), the other possible way to express our need is to VOTE. I already placed my vote. Don't await that this will implemented, without your vote. Your votes shows your and our needs! So you who read this, and want to say that you need the ALT tooltips feature, place your VOTE! Thanks, Webmaster33
Comment #231 must have the record of the longest comment ever on Bugzilla :-) I'm glad Bugzilla didn't mess up on that. :-)
*** Bug 191728 has been marked as a duplicate of this bug. ***
*** Bug 192494 has been marked as a duplicate of this bug. ***
This has been beaten to death. Suggest alt text show in quirks/legacy mode, but not in normal mode. Now let's move on. ________________ Marc Stager
Another Dup fromm A noob who will probably now go back to IE *Cough*bug 74241*cough*
*** Bug 192603 has been marked as a duplicate of this bug. ***
I tried and tried to resist, but this is such a great example of why NOT to use TITLE-like text for ALTs that I finally gave in. From comment 231 : <quote> "Hover your mouse curser over their logo, and a tooltip will pop up and say "Google". What good does that do?" Sometimes it says something different, like "Happy Martin Luther King Jr. Day" or "Happy Chinese New Year". By hovering in MS IE, I was able to figure out what the special logo for the day meant. Not so in Netscape 7. (And even if these aren't the perfect examples of ALT texts, they aren't so bad that they would seem to screw up any graphicless browser that reads them.) </quote> ALT text is essentially a non-graphical equivalent for the *functionality* of graphics used as navigational links, etc. In lynx, a link with the ALT text "Google", leading to Google's home page, provides pretty much the same functionality and information as the clickable logo. ALT text of "Happy Chinese New Year", though, is useless as an indication of the result of following the link, however captivating it may be as eye-candy, or whatever. Bad ALT text like this won't screw up a "graphicless" browser (the software), it screws up the browser's *user*. Someone was asking (way up there) about real-world damage done by the confounding of ALT and TITLE purposes. 'zat work? PS: For extra credit, turn images off, and then find the link to www.mozilla.org (other than this one) on this page. I believe there's only one, and it's invisible :)
Quoted: In lynx, a link with the ALT text "Google", leading to Google's home page, provides pretty much the same functionality and information as the clickable logo. ALT text of "Happy Chinese New Year", though, is useless as an indication of the result of following the link, however captivating it may be as eye-candy, or whatever. Bad ALT text like this won't screw up "graphicless" browser (the software), it screws up the browser's *user*. (/quote) Thank you for at least providing what seems like a well-reasoned argument, unlike many of the others addressed in comment #231. However, this one doesn't have the facts straight. You speak about "the result of following the link", however, what was being discussed wasn't a "clickable logo" as you call it. It is a graphic, and it isn't a link. The graphic didn't just say "Google", it was a modified graphic for the holiday in question. Therefore, ALT text of "Happy Chinese New Year!" is an appropriate text replacement of the graphic which was clearly modified in order to celebrate the Chinese New Year. It would not screw up the non-graphics user any more than the custom holiday graphics screw up the graphics user, so if there is screwing up the browser user than its at least being done equally and therefore the ALT text is perfectly doing its job of serving as a graphic replacement. Today Google is displaying it's normal logo, and the ALT text is simply "Google". Which, once again, is an appropriate replacement of the graphic. The faultiness of this response is solely in the specifics. At least it seemed like this writing tried to be reasonable. It is clear that the people in charge of how Mozilla develops have their own viewpoints and are unwilling to succumb to any new discussion, ignoring the problems with the road they've chosen including the numerous examples pointed out of faultiness in their own logic, other arguments claiming a greater negative will happen than the theoretical one feared by the anti-ALT tooltips group, backwards compatibility on older pages that won't be updated, and popular opinion (all except possibly the last of which are good reasons why ALT tooltips should deserve being addressed.) Although the download at http://white.sakura.ne.jp/~piro/xul/xpi/popupalt.xpi (a web page not viewable in MS IE) does seem to address this problem, it's just a shame that users are expected to have to download something extra in order to view older web pages which used proper tooltip/speech-browser/textmode-browser ALTernate text using the standards of the day. After all, the vast amount of pre-existing web sites, including those with graphics, are what was primarily responsible for the Internet/web boom during the 1990's and there are numerous pages which are great sources of information but which aren't updated. This vast set of data is the reason most people even obtain web browsing software in the first place! I would think that simple web pages (which don't rely on scripts or other advanced technologies) dug up off of a five year old CDR ought to work as they were intended, but noooo... The Internet's already-existing resources are apparently worthless: the only thing that's important to the people in charge of Mozilla appears to be the future pages. If theory, not usability, is the primary concern, why even bother with HTML or http? The lack of response to Comment 231 has communicated clearly that Mozilla's team in charge don't care to discuss this issue despite the numerous problems pointed out with the road being taken. I don't much like the idea of recommending Netscape 4 as the tool of choice for looking at the archive of an older site, but clearly newer browser versions are less compatible and the philosophies stated for why this is the case only suggest that such incompatibilities will only grow over time as newer versions phase out more compatibility as more things are considered "old". As is, Netscape 4 is worth keeping around despite being buggier because its bugs are the occasional problem that occurs due to programming mistakes, not deficiencies that will invariably occur every time due to intentional design.
Whilst comment 239 wasn't entirely correct in that context, it is correct that Google uses alt text wrongly for special logos. The google logo at the top of each page is the page title (and should really be in a heading tag). The alternate text of "Happy whatever day" is clearly no substitute for the word "Google" as a title. It would be more correct for the *title attribute* of the image to contain some information about the special logo, as this is where information about the picture should go ("offers advisory information about the element for which it is set"). The reason they failed to do this is possibly because some browsers would fail to show the title as a tooltip, prefering to show the alt text.
The correct ALT text would have been something akin to: "Google. Merry Christmas!" or "Google Wishes you a Merry Christmas". Anyway, as I said... It would be nice for a webmaster to go through and validate their pages and check that their ALT and TITLE attributes are correct, but a webmaster need only to write a simple 5-line perl script to go through and change all their files' ALT attributes to TITLE. I almost wish we had a button that had some pre-set evangelism notices that allowed a user to simply put in the email of the webmaster and press send. Perhaps thousands of complaint emails from different users would get their attention (or backfire on us) ;-) On another note: I'm curious why their is an ALT attribute and why ALT text isn't done as following: <img src="">Alt text goes here</img>.
> The correct ALT text would have been something akin to: "Google. Merry Christmas!" or "Google Wishes you a Merry Christmas". That would be better, yes, assuming they are trying to communicate "Google". It is also possible that the reason it still looks kinda like "Google" is just from the remains of what was on that position of the site on a previous day, and isn't really intended and that all they are really trying to say is "Merry Christmas". This is less likely, though, I do agree that their ALT tag is most probably... imperfect. > Anyway, as I said... It would be nice for a webmaster to go through and validate their pages and check that their ALT and TITLE attributes are correct, Bah. All the validators validate to HTML 4 or XML or some ridiculous nonsense like that. There may be some webmasters who still purposefully code to older HTML standards which browsers can render perfectly, but all the validators at W3C are useless because they will complain, "tag HTML is not specified in DOCTYPE" or some such message. Coding to the simple old standards (ignoring scripts) works in any browser and web-reading software I've seen except for those whiny validators, and NS6+ not properly supporting ALT tags without an add-on. > Perhaps thousands of complaint emails from different users would get their attention (or backfire on us) ;-) Of course, there are those who are even aware of the issues, and will just tell users to stop complaining about the limitations of the browsers they choose. I for one see no reason why I should change every HTML file I've ever made just because some users choose to run a browser that purposefully fails to do what the users want because the maintainers of the software refuse to put one line of code, already written for them, into the default build. Those who are frustrated at how much traffic this one topic gets (I believe ian@hixie.ch qualifies) maybe should begin to consider that their dreams of dropping support for B and I and U tags in favor of CSS, and dropping IMG tags in favor of OBJECTs, will cause far more people to notice problems than this one ALT issue, and more people will complain and voice objections as support for more noticable things are dropped. It is disheartening to see a useful site go down because of unavoidable things, such as a college cleaning off their computers and erasing a student's directory getting wiped by the university after the student stops going to school. If the masses ever start moving to newer Netscape software, the majority of people interested in useful software, not tech-geeky stuff like revisions of standards, will quickly abandon newer versions that drop support for these older tags. > but a webmaster need only to write a simple 5-line perl script to go through and change all their files' ALT attributes to TITLE. This requires that A) The webmaster knows perl and B) That the webmaster has a perl interpretor on the system and C) That the webmaster doesn't care about Netscape 4 users (and isn't under orders by superiors to keep NS4 compatibility) and D) That the webmaster has access/permission to update the files (which isn't true on read-only archives such as on CDs or on the Internet Wayback Machine at www.archive.org) and E) The webmaster has enough free space on their web server to fit an extra two bytes for every old occurence of ALT and F) The webmaster doesn't mind having their file dates and times modified. Admittedly, points E and F seem to be getting to the point of frivilous argumentation, but points A and B and in some cases D prevent me, for example, from being able to do that and point C prevents me from being willing to. >I almost wish we had a button that had some pre-set evangelism notices that allowed a user to simply put in the email of the webmaster and press send. Personally, I would favor numerous such buttons: Contact Webmaster with pre- written evangelism code would sound useful, as would simply a Contact Webmaster button, as would be a "Contact previous site's webmaster to tell them that the site linked to, which I've now gone to, is a 404" (or a newly-created porn site or some such nonsense). This would help search engines as people would be more likely to complain about bad links, as well as newbie webmasters or maintainers of old, infrequently-maintained sites. I'd welcome more discussion on this, although this isn't the thread the be discussing new features such as this. If you submit such an idea through the formal processes, be sure to post a link to those topics and I'd be interested in them. > On another note: I'm curious why their is an ALT attribute and why ALT text isn't done as following: <img src="">Alt text goes here</img>. Backwards compatibility, my friend. Before the later standards that told people to put EMBEDs into OBJECTs and the EMBEDs would be ignored, stuff in tags were generally rendered. This is why (NOSCRIPT)...(/NOSCRIPT) worked: The newer browsers supported SCRIPT and NOSCRIPT, the older browsers didn't need to support it. The IMG's ALT attribute predates the newer style of ignoring what's inside something renderable.
"Perhaps it will backfire on us". Oh yes, it will. Mozilla is a browser, and a browser's job is to display the web, not to change it.
I'm sorry to be cynnical, but if people dropped their support for old browsers, there would be no issue. People don't support NS1 on sites, do they? Why support NS4? Without support for NS4, people would upgrade. If people want to view a page, and don't have the hardware necessary to use a newer browser, they can use Lynx. Now that a lot of palmtops can display HTML, you have much bigger problems. Every page you designed with the expectation of a high resolution computer monitor ( > 320x200) won't work correctly. This is your fault for using absolute widths on your page. >A) The webmaster knows perl and B) That the webmaster has a >perl interpretor on the system and C) That the webmaster doesn't care about >Netscape 4 users (and isn't under orders by superiors to keep NS4 >compatibility) and D) That the webmaster has access/permission to update the >files (which isn't true on read-only archives such as on CDs or on the >Internet Wayback Machine at www.archive.org) and E) The webmaster has enough >free space on their web server to fit an extra two bytes for every old >occurence of ALT and F) The webmaster doesn't mind having their file dates >and times modified. Admittedly, points E and F seem to be getting to the >point of frivilous argumentation, but points A and B and in some cases D >prevent me, for example, from being able to do that and point C prevents me >from being willing to. A) You can use anything else -- BASIC, shell scripts, C B) There are FREE perl interpreters for every system, even Mac and Windows. No excuse. Why would you not have a perl interpreter on a web server? Oh, you write all your CGIs in QBASIC, huh? C) Write two versions of your page, and provide a link -- in a way that is visible older browsers -- to take people to a quirky page that is designed for older browsers. D) If you do not have access to your web pages, then there is a problem, isn't there? If a Web Archived page doesn't render correctly on a new browser, get the older one. That is a ridiculous requirement we support pages from 1998 that aren't even on the web anymore. There is probably a 100,000:1 ratio of webmasters to mozilla developers. We cannot cater to your every whim. E) Get a bigger hard drive, or use templates (http://www.template-toolkit.org/) I cannot believe you would write a large site in pure HTML with no templates. What a waste of time! Bugzilla uses templates. F) That can be avoided. Yes, frivilous. By 2010, supporting NS4 won't be an issue anymore, and this "bug" won't even be a concern to you. Besides, you can blame this all on browsers not following the standards. If browsers followed the standards, people would learn them. I'm sorry that you would rather we bloat our software trying to figure out every insane breach of the standards people would try, rather than following the standards. While you complain about browsers following the standards (as you are appearing to do here), I have complained for years about the opposite. Appears we have a conflict of interests, huh?
Netdemonz, The biggest problem with you is, that you think you can tell how the internet should work. No, you can not force people to use 6.x, 7.x browsers, nor you can force webmasters to not support NS4 compatibility. Visitors want compatibility with older browsers, too. There are millions of websites, which will be never updated for latest html standard... You can not change that fact. A programmer is not master, is servant, who satisfies public needs... And the public says, ALT tooltip is wanted! What proof do you need? More than 200 posts proves, that this subject is popular and most browser users wants it. Also there are already 18 votes to have it implemented. Why not satisfy both group? Add the ALT tooltip feature in Quirks mode (several good, acceptable solutions was suggested), and put an OPTION to Preferences, for those who want it TO TURN OUT. This way both groups are satisfied. And those, who don't want ALT text to display as tooltip, will simply turn it out in the Preferences. It's easy like that. Webmaster33
A hidden pref for this would be fine for people who watch this bug. Especially one you could turn on and off with a bookmarklet. The issue comes in that only a tiny percentage of users will know of this. Turning it on for quirks mode only will lead to questions of: "Why does this not work correctly on this page?" when they put in a doctype because they think quirks mode is the correct behavior. The best proposal so far was to turn on the ALT tooltip when images are displayed (bug 88297) and no TITLE attribute is available. The question is whether we want to do so when it encourages writing bad pages. You can take this to the newsgroups, but it is not really a big issue and it is dead here. Most of the people that would decide to change the policy are not CCed anymore and people are slowly removing their email addresses from the CC box. I feel, like so many other issues, this issue will fade away with time. Eventually, Netscape 7 will be considered an old browser, and no one will have Netscape 4. Things like XHTML are going to make Netscape 4 obsolete once Internet Explorer supports it. I ask myself why I don't remove my email, but since this bug only has intermittent noise, I don't bother. Besides, there is occasionally something useful said. I'm adding this as a blocker for bug 169476 -- "Bugs that annoy bugzilla users reading bugmail"
Blocks: 169476
No longer blocks: 169476
I realize this could be argued to death, so I'm going to continue my practice of limiting my responses (which is why I didn't respond at all to some other comments). Like your response in point C or Phil Housley's comment #241, which I simply had no disagreements or worthwhile comments to make on, so I thought I'd not grow the list more. NeTDeMoN: First Statement: Software should be useful. Point D) "That is a ridiculous requirement we support pages from 1998 that aren't even on the web anymore." But the whole point of web browsing software is that it can render pages on the world wide web. That's the singular top reason why people even use web browsing software, instead of other software which may have some superior capabilities such as Word or PowerPoint which can zoom out and display multiple pages at once. The reason people like the web is because they can link to other resources on the 'net, and that includes the old ones. The common argument that Mozilla dev'ers shouldn't need to support EVERY oddball thing is understood, nobody here is asking for LAYERS support so as to fix all the old scripts. What's asked for on this thread is full support for the simple version of HTML (excluding plugins) that everyone was using in 1993, which to my knowledge is currently supported by NS6 in every example except for ALT tags. To address numerous other comments, Second statement: People are different. Example: Point B: "Why would you not have a perl interpreter on a web server?" The number one web content holder used for development is: The local hard drive. Most systems people actually use do not have perl interpreters installed, including many/most university lab computers where people can't go around installing programs. Expecting people to learn perl before they can make HTML is even worse than expecting that CSS's (font style="font-weight:bold") is easier for a newbie to intuitively grasp than the (B) tag. "Oh, you write all your CGIs in QBASIC, huh?" No, I do not write all my CGIs in QBASIC. (I know, that was rhetorical.) Truth is, I don't write any CGIs whatsoever. Though I've personally created multiple websites which are hundreds of megs big (no, these weren't file archive sites), I've virtually never used CGI at all, and the two frivolous times I did certainly didn't involve me coding CGI any from scratch. Which is really the number one reason why I don't have perl installed: It's not as useful as many people make it out to be. Point E): "I cannot believe you would write a large site in pure HTML with no templates." Did it once, made a large site (150MB) in pure HTML. In more recent times I've used JavaScript to handle lots of automation. JavaScript, unlike Perl, requires NO special software stored on the server and works well when loading pages on your local hard drive without needing perl installed. I currently think that NS4 is obsolete, but it will continue to be an issue just as much in 2010 as it is today: Archiving software capable of displaying older pages (or simple pages using older technology). Which are the main reason for the average use of a WWW browser. As palm pilots and cell phones become more and more used, space considerations and slow processors will continue to make low-end compatibility issues not go away. MS-DOS is an often emulated operating system for low-tech devices. I can fit MS-DOS, Windows 3.1, and Microsoft Internet Explorer in about 15 megabytes installed. Offhand, I'll just assume Netscape 4.08 for Windows 3.1 is roughly the same size as the Windows 3.1 MS IE's. NS7+ takes up twice that much space alone when compressed (uninstalled), not to mention Windows 95 or Linux+XWindows ontop of that. For these reasons, I'm more likely to put the MS- DOS install files and other needed files on a crowded CD than NS7. Which, since I'm mentioning an MS-DOS environment, I'll move onto point 2. As for your last comment, I am not complaining about following standards. I am in fact arguing for support of the 1993 standards still in use today. You are on the side of supporting only the latest standards and dismissing the older standards, while I am a proponent of higher compatibility. I believe that the newer standards you've argued in favor of for years are great: Standards bring about compatibility and they are great. I'm just not in favor of dismissing the old ones.
Netdemonz, >The best proposal so far was to turn on the ALT tooltip when images are >displayed (bug 88297) and no TITLE attribute is available. Yes, I aggree. This would be the best solution. >The question is whether we want to do so when it encourages writing bad pages. Well, it would be a compatibility feature for traditional reasons. IE 4.x, 5.x, 6.x (95% of users) already "encourages writing bad pages", Mozilla will simply not matter in this fact. The question is, does it worth losing users just because Mozilla doesn't support, a traditional (compatibility) feature? I think this small compatibility feature worth a Preference option to satisfy all users. Webmaster33
All the discussions about standards IMHO include one common mistake: Standards are treated as being the ultimate orthodox word of truth, which they arent't. HTML 4 was conceived in 1997, laid down in 1998. And still, six years later (!) in 2003 not one single browser does 100 percent support for it. Mozilla is good, but not perfect in sticking to the standard, and not even W3's own browser, Amaya, has all features of HTML 4 or CSS implemented. There is no reference browser anywhere. On this background I believe dreaming about XHTML is pure science fiction. Although XHTML is around for a couple of years, still AFAIK practically nobody does XHTMLon the web - I have seen it only on intranets. There are reasons for that. What about sites that use frames? Frames have been kicked out of the standard by the W3, "not invented here". Does anyone really believe that on a large scale basis anyone will rewrite entire websites that use frames to do the same thing - but far more complicated - in CSS2? Yes, it is desirable, but no, it is unrealistic to demand everyone sticks to the standard. Sometimes going beyond the standard is practical. In pure HTML it is impossible to set the height of a table. You can only do this with CSS... In pure HTML 4 you cannot set frames seamlessly next to each other. The tags that accomplish this are recognized by all browsers (including Mozilla), but they are definitely non-standard. As I said, browsers have to display the web, in all its impurety, and it is _not_ their job to teach webmasters lessons of how they should do their job.
bugzilla_alt_tooltips@toogam.bespin.org: >I currently think that NS4 is obsolete, but it will continue to be an issue >just as much in 2010 as it is today: Archiving software capable of displaying >older pages (or simple pages using older technology). Which are the main >reason for the average use of a WWW browser. You can find all older versions of browsers on the internet. THAT is what you should use to view archives, and not expect a browser to support non-standard things like <blink>. Seriously. HTML has changed a lot since 1993. To expect a browser to bloat their code by supporting every permetuation of what has been supported at the fault of standards, developers, and browsers in the past is ridiculous. Its like asking lockmakers to still support skeleton keys or car designers to use both fuel injection and carberators on the same car. If you want to view archived pages, then get the old browser. Its that simple. You can also run it through HTML Tidy on www.w3.org and hope for the best. http://www.w3.org/People/Raggett/tidy/ Its really ideas like this that have kept technological evolution from moving forward. Dragging along old standards just complicates improving them. There needs to be a time to just toss them in the trash and start over. >As palm pilots and cell phones become more and more used, space considerations >and slow processors will continue to make low-end compatibility issues not go >away. MS-DOS is an often emulated operating system for low-tech devices. I >can fit MS-DOS, Windows 3.1, and Microsoft Internet Explorer in about 15 >megabytes installed. You can't run MS-DOS on a palm pilot. Unlike Linux, DOS isn't ported to many platforms. You are stuck using the integrated operating system on a palm top and browsers that basically do nothing but render pages. They won't be able to afford to put in backwards-compatibility measures for every permetuation of standards-breaking pages and browsers. They will probably be very very picky on syntax, order of tags, etc. In fact, that is why XML and XHTML is extant because it forces the issue. >In more recent times I've used JavaScript to handle lots of automation. Javascript is turned off by a lot of people and isn't supported on Lynx. CGIs OTOH don't have this issue because they don't necessarily require javascript. > I'm more likely to put the MS-DOS install files and other needed files on a >crowded CD than NS7 I've thought many times about porting Mozilla to DGJPP for DOS. I don't know how useful it would be. Regardless, it would still have the same standards requirements. > Standards bring > about compatibility and they are great. I'm just not in favor of dismissing > the old ones. That's where we disagree. If you have an old page and don't want to update it, make an agreement with Netscape to allow people to download NS 2.0 and IE 3 from your page to view your content. The standards were agreed upon by not only many browser developers like Hixie from all companies and groups that develop browsers but also were argued about extensively on W3C mailing lists. They WILL make our lives easier once everyone adopts them, and we choose to push the issue. Not following the standards brought you NS4 and pure frustration at nothing working right on all the browsers. You have to respect that we would stand up for what we believe in and feel we are doing it for the good of everyone on the www -- even if you disagree that it is helpful. Really, in the end... Isn't an argument about tooltips kind of silly? For instance, I don't even look at them. Oliver: You are contradicting yourself. HTML _was_ meant to be an evolving standard, not set in stone. You are all complaining that it isn't expected to be an orthodox standard and unchanged for all of time. Browsers display the web as the user chooses. Not as the webmaster decides. There is no way to force a page to look a certain way on a system. A lot of pages are based on this faulty idea of forcing a page to look a certain way instead of gracefully degrading for systems that can't support it looking a certain way. That is why, in theory, all pages should be readable on Lynx. And I'll tell you.. Before I got the NVidia drivers needed for X Windows on Linux, I was damned happy NVidia had the decency to make it look readable in Lynx. http://webtips.dan.info/ Before people complain about the standards, why don't they try to support them? If you actually understood the standards, you could go ahead and converse on the mailing lists that need to be changed.
"Its like asking lockmakers to still support skeleton keys or car designers to use both fuel injection and carberators on the same car." No, because both injection and carburetors take the same kind of fuel. It's just the other way round: As a car maker you cannot expect governments to update all their roads because you switched to New Technology tires and you cannot expect oil companies to update their fuel, just because your new injection is technologically superior. People want to drive and not bother whether their injection adheres to standard A or B or none at all, as long as it takes _their_ fuel and runs on _their_ roads. What made the web so popular was the fact that you didn't have to bother to run the "right" operating system or the "right" program to view documents. Just having the lasted browser was sufficient, and that's the way it should be. You really cannot expect that people have two, three or four browsers for all kinds of documents flying around, _that_ is ridiculous. Indeed, I _do_ expect one browser to fit all kinds of documents on the web.
> Browsers display the web as the user chooses. Or, in this case, as proven, as the browser maintainers dictate... > car designers to use both fuel injection and carberators on the same car. If you want to view archived pages, then get the old browser. A far better analogy would be to say that I want car designers to make cars that are capable of driving on the same roads as every one I've used in the past, as like the websites out there, they already exist. Bah, okluge just posted this exact same analogy. Well, for humor's sake, I won't delete the next paragraph: I'm glad that Moz developers aren't in charge of designing cars. "A gear the size of the average car's fifth gear is plenty good, and we even still have 'Quirks gear' the size of a fourth gear. Vehicle manufacturers should not be expected to have to keep creating gears the size of the standard first gear, it's a waste. "What? You want to be able to drive on all roads, not just freeways? Forget your silly demands, freeways are better, cleaner, faster, safer, and the way of the future. If all city governments would just buckle down and pay for their roads to be widened to freeway standards..." "I mean really, in this day and age, stop signs and traffic lights and streets near schools are not a good reason for vehicle manufacturers should continue to be made that can travel slower than 40mph. If roadbuilders everywhere would just make bridges at every intersection than you'd have a faster and better driving experience for everyone. Eventually citizens will come to demand this and collectively vote to spend $4 million per street for road upgrades. To help make this happen, Moz's Evangelism team will help with the effort." > If you have an old page and don't want to update it, make an agreement with Netscape to allow people to download NS 2.0 and IE 3 from your page to view your content. To expect people to download an entirely different browser just to view a page is an even more offensive idea than requiring a standard plugin like Flash (which works on multiple browsers). > I've thought many times about porting Mozilla to DGJPP for DOS. Off-topic but of interest so I'll tangent: DJGPP has the same problems Linux does. Commo 5.3 works on the HP 95LX palmtop. Commo 6.0 works on the HP 100LX, and my guess offhand is that the HP 100LX simply has more than 64K of RAM for DOS apps (as Commo 6.0 included internal ZModem and so grew). Electronics which have enough horsepower to run Linux are generally powerful enough to run DOSEmu, which is why I was saying that DOS programs are the more widely compatible proggies. Wouldn't it be easier to port a program like a web browser to the GUI-ready Windows 3.1, which has the added benefit of working on 286's? If this were done, would you write an interface for plugins made for the old Netscape, since you know that Windows 3.1 plugins aren't going to be updated, or should the makers of these discontinued apps be expected to update to the new plugin interface if users want fancy music on the web? Still, if Moz was ported as a 386-only app for DJGPP, it'd sure as heck beat the stuff I've seen for DOS and put off messing around with (which have far more serious deficiencies than ALT tags).
Sure, my comment #231 (my first) was fairly large. There's one part that I was surprised didn't get any comment on it, and I now have a new thought to add onto it. As a specific request for comment, I'll re-iterate the specific part I've stated before in 231: If the ALT tags showed an ugly green "ballon help", and the TITLE tag displayed "ballon help" with a white background, and in the event of both ALT and TITLE there would be white-bg'ed baloon help under the mouse curosr and an ugly green "ballon help" under the white baloon help, then ALT tags would look different than TITLE tags, people could see that there is a difference (and would lean towards preferring the prettier TITLE tag), and those with huge compatibility concerns could be satisfied because ALT texts could actually be seen, and those who aren't in the know wouldn't assume that there is a bug the way many do now from the apparent complete non-support. This seems to solve everyone's primary goals, and such an alternative is kinda what comment #223 was getting at: Most of the Pro-Alt-Tooltips people don't care if it looks like a standard Tooltip, just that the information isn't fully, totally ignored. Okay, now for the new stuff: It seems that some people dislike having tooltips at all. So, rather than have a checkbox for tooltips regarding ALT tags specifically, if ALT tags aren't enough of an issue, perhaps a radio button for tooltips with three values, Off, Title-Only, Full-Alt Support. Now, from what I've been able to tell, it would seem like Moz is trying to make more of the browser customizable, even the browser interface which is modifiable (and can be viewed at the address chrome://navigator/content/navigator.xul ). Can't tooltip support be user modifiable through this sort of interface? It would seem from this massive toolbar customizability being made that the attitude of the Moz dev team really isn't against having another preference in their browser, they do want it customizable. They just don't want to add a rather useless feature to an already-crowded Preferences Window under the Edit menu, but other methods of customizability is A-OK. The problem with the JavaScript solution posted in comment #133 is that the JavaScript will only work on a site which I have write-access to, and can only modify my browsing experience if I have JavaScript enabled. However, http://devedge.netscape.com/viewsource/2002/toolbar/ mentions a devedgetoolbarOverlay.js file, and toolbars are able to survive a browser changing pages. Could this be applied with #133's JS to provide a solution without the Moz Dev team needing to "add support" for a silly little thing? For those who suggest sticking to the standards, I respond, how about providing a standard where tooltips can be controllable? This way, if some screwball like myself comes up with some terrible new idea like two tooltips (which still hasn't been responded to) then the response can be "yup, it can be done." Can new toolbars/status bars/etc. currently be loaded from remote? (chrone://http%3A//www.something.ext/fav_toolbars/choice_toolbar.js) Thinking out loud, I think it'd be a highly abusable, but useful, ability, as well as other JavaScript. (Sorta like the &quot;bookmarklets&quot; that Sega Dreamcast web browsing users are so fond of, except that they could be running over multiple pages and so wouldn't need to be manually exectued as the on-command DC bookmarklets are.) (And the proper approach, by the way, is, like popups, to see how abuse of this could be controlled, not to disregard such an idea because it would be abusable.)
Whiteboard: (SEE COMMENT 153!!!) → (SEE COMMENT 153!!!) (and 204 for workarounds)
First of all, I'd like to make sure you realize that what you say here is most likely not really going to change anything. You are arguing your case, which is fine -- and if people get annoyed, they can remove their email from the CC list. I'd just like to mention that. Your best bet is to bring up bug 88297 in the newsgroups, as this bug is basically dead and we are basically just discussing standards issues. I agree with you that some browsers supporting the standards, and others not provides a dilemma. I don't know what we can do about it. You should probably realize that there has already been a major version of Netscape (version 6) that went through without support for ALT tooltips, along with many minor versions of 7 and all Mozilla versions. Therefore, IMHO, if you consider it damage, its already been done. The precedence has been set, and changing it now would just make things even more confusing for people. > Wouldn't it be easier to port a program like a web browser to the GUI-ready > Windows 3.1, which has the added benefit of working on 286's? No. DGJPP would be better. Windows 3.1 has too many limitations. AFAIK, DGJPP is supported still, while Windows 3.1 isn't supported by Microsoft. I'm actually glad that we have to make developers choose between Mozilla/Netscape 6+ and NS4. NS4 is a disgrace, and I want to see it go away. Since I don't work for Netscape, I can say that I really don't care if you want your pages to also look good in NS4. Solution: Do not write pages for NS4 or make alternate pages for the older browsers.
Brian, no one is going to be removing people from anything. So don't threaten people, please.
Brian 'NeTDeMoN' Bober said: >> if people get annoyed, they can remove their email from the CC list. I'd just like to mention that. Boris Zbarsky said: > Brian, no one is going to be removing people from anything. So don't threaten people, please. I believe he was saying that on an individual basis, each person could remove himself/herself from this thread if (s)he wanted to. There's no threat there, and some people in fact have been leaving. NeTDeMoN: Thanks for the pointer to 88297. Somehow it didn't seem like a complete re-hash of this discussion, unlike some of the other bugs I've followed the links to.
I've said that in a newsgroup discussion long ago: The easiest way to make this bug go away, without explicitely fixing it (which will never happen, we are repeatedly assured), is to honor an onpageload.js file, which will be executed on each page load (surprise!). There the #133 JavaScript can be inserted. Or, if you're feeling bored, BORKify each page, etc, ... Regards, Peter Jacobi
NeTDeMoN: I also thanks for bug 88297. I placed my vote there, too. Sometime, somebody will note if there are a lot votes in a bug and do something...
>------- Additional Comment #256 From Boris Zbarsky (On vacation for real) >2003-02-25 21:55 ------- >Brian, no one is going to be removing people from anything. So don't threaten >people, please. Which is, of course, not at all what I said if you had actually read my statement. Comment #257 correctly explained what I was saying: >I believe he was saying that on an individual basis, each person could remove >himself/herself from this thread if (s)he wanted to. There's no threat there, >and some people in fact have been leaving. This is only two weeks after you complained to me that I should be more careful I have the correct information before replying to a bug comment. I recommend you be more careful before replying to bug comments -- especially any accusary statements. Since I am aware you know English perfectly well, you should not have any problem understanding what I said. What I said was: >First of all, I'd like to make sure you realize that what you say here is most >likely not really going to change anything. You are arguing your case, which is >fine -- and if people get annoyed, they can remove their email from the CC list. >I'd just like to mention that. "they" refers to the people that get annoyed. "their" refers to the email belonging to the botheree, not the botherer -- whom is referred to as "you" (meaning the person towards which I was addressing the comment). My comment might have been a bit pronoun heavy, but if read properly, is obviously not any kind of threat. The only time it would appear as a threat is if you are looking for a threat even though one is not there in order to get pleasure out of reprimanding someone.
What's the likeliness of what Peter Jacobi said in Comment 258 actually happening? Intuitively, my first thought would be to think it wouldn't, but if the browser's toolbars use non-remote JavaScript (like devedgetoolbarOverlay.js) then that contradicts some of the intuition that dismisses such an idea. Is this going on in some way, using the name onpageload.js or any other?
This may not be a "bug," but it is a feature that is lacking from Mozilla. * The Web came first, not Mozilla; and alt text for images came first, not the title attribute. Before the new W3C specs threw it out, displaying alt text as a tooltip was very appropriate, as it described the image. * Mozilla is and always will be a niche-browser, despite its magnificent quality. Thus it's silly to assume not supporting something in it will cause the Web to shift greatly. It will not. * Many website builder tools, including Dreamweaver and Frontpage, use alt text instead of the title attribute to describe an image. Many users use these GUIs and exhibit 2 important traits: 1) They are not geeks, and so do not know HTML, what Mozilla is, nor web standards. 2) They understand alt text to be how to make a tooltip appear over their images. Even if these website builders were somehow made aware of the error their GUI was causing, they would be unable to resolve them (if they even cared) on their own. This is not only because they do not know HTML, but because they generally use these GUIs to build and maintain pages quickly - for example, dragging images into a page from their hard drive, typing some text and moving on. Thus even if they were taught basic HTML, asking them to go in and fix their broken GUIs behavior would be excessive. I have an excellent case in point - http://thestate22.com/ - It is too Mozilla's credit (and I am proud of Mozilla for it) that it can even render this site, as it's built with Frontpage. But it is to some people here's discredit that it does not display tooltips over any of the images. This feature needs to be enabled, at least as an option in Preferences that is, by default, disabled, just so those with a stick in their ass can still make their point that "It shouldn't be how you make a tooltip if you want to do it right." Much of the Web is too busy to notice, and all I want as a Mozilla user is to be able to enjoy *all* of the Web without leaving this pretty browser.
Chris, Comment #262: >This feature needs to be enabled, at least as an option in Preferences that is, >by default, disabled IMHO by default should be _enabled_, because many beginner users does not know why the tooltips are not displayed. They would not even know about that option. Advanced users, who don't want that feature enabled are much less, and they know where to disable this option, if they don't want this feature.
> Thus it's silly to assume not supporting something in it will cause the > Web to shift greatly Yeah, it's silly to assume that not supporting document.layers or document.all will cause web sites to start using document.getElementById. Total lunacy. No one will ever do it except the vast percentage of the "top100" sites that _have_ done it, the authoring tools like Dreamweaver that have added support for it, all or the webmasters who either copy said top100 sites or use said authoring tools. That's what it's all about, really, as you pointed out. Authoring tool support. Everything else is pretty much irrelevant. And the people who write authoring tools _are_ people who understand HTML and _can_ be swayed on this issue (to generate "title" tags when the user adds a "tooltip").
Actually I think Mozilla's support of DOM-1 (and document.getElementById) and not supporting document.layers is quite valiant. This feature carried over into Netscape 6/7, a browser for the masses (hopefully in AOL someday), and finally put Netscape 4, one of the worst browsers ever made, to its death. document.layers was very limited in its functionality and never made it into many WYSIWYG editors, so it's not damaging to a user of Mozilla that it's not supported. I certainly didn't miss it. But Netscape 4 was a minority browser with a poor implementation (thus Mozilla). Alt tags as tooltips had excellent rationale when this feature began, and all browsers until Mozilla adopted this functionality - not one minority, or even majority browser, but the entire Web. I entirely agree title is the proper attribute for this scenario, but the "top 100" websites are not the entire web - they certainly don't encompass the majority of my browsing. It is valid that if this hard line remains in Netscape 6/7, as it has, that some GUI makers will realize this and resolve this in their next software version (for example, Macromedia will fix it ASAP). But it is also valid that, because alt attributes are so widely used by low-level authors in varying ways, lack of tooltips for alt text in NS 6/7 will instead be viewed as a *weakness* by the average user. And don't think Microsoft will keep from exploiting this weakness. If this "feature" remains as it is, I'd be surprised to see the next version of Frontpage use title instead of alt for images. I return you to http://thestate22.com/ as a good case in point. The user who writes content for that site has been provided that space with Frontpage Extensions only - that means that no FTP access is configured, and therefore he can publish to it only with Frontpage. It is the only ad-free, free hosting he has available. This situation is unlikely to be unique (I know that at least 20 other users on this same webhost are in the same situation). His natural decision then is to stick with Frontpage, even though as a mindful developer I've made him aware of its long list of failings. This scenario has 2 possible conclusions: 1) Microsoft never uses title attributes for images in Frontpage. thestate22.com and sites like it thus never convert, and thus Mozilla and Netscape 6/7/X forever offer the user an inferior experience on all such sites. 2) Microsoft finally uses title attributes for images in some future version of Frontpage. Some of the users upgrade eventually, maybe. Thus Mozilla/NS offer the user an inferior experience on almost all such sites, with very slow, trivial progress. Why is this beneficial to Mozilla/Netscape and its users? It's not.
The top 100 sites are not written in Frontpage and are generally written with CGI scripts and templates with SQL queries defining what data they pull up and templates that are easily modifiable wrapping that data. The switch will be easy for them, if not already done. I have another suggestion: We could add a some META attribute, or something that allows people to have ALT tags displayed on web pages they add it to. Adding it would make them aware they are breaking the standards. I'm sure this will be shot down, but its just an idea. I wonder, though, how this is such a big issue. I mean, in the grand scheme of things, isn't this rather trivial? I also wonder what the older standards said about ALT and tooltips back in the days of IE4 and NS4 or even NS3... Does anyone know?
netdemon, IMHO you're missing the point. if you can get the page author to add a META tag, he could just as well have changed ALT into TITLE. the issue is existing standards compliant pages, which are kept on the web for reference and archival value. contrary to the belief of many contributors on this bug discussion, there are a great many HTML 2.0 and 3.2 pages which still are useful. asking authors to update their HTML 3.2 to XHTML doesn't make sense. why should they? their pages follow the spec. TITLE was not a defined attribute for <IMG> in HTML 3.2 and earlier. if you worry about standards conformance, the TITLE attribute should rightly be ignored in a document declared as HTML 3.2. Mozilla gets this wrong, currently.
Then they should put an HTML 3.2 doctype at the top of the page.
As a followup to NetDemon's response: If they do, ALT tags still aren't shown as tooltips. Nor are they on documents properly treated as HTML 2.0 PUBLIC.
*** Bug 197603 has been marked as a duplicate of this bug. ***
*** Bug 199126 has been marked as a duplicate of this bug. ***
First I read ALL 271 Comments, so I'm informed. Before I read this Report I like Mozilla and I thougt that where a Bug, but now I know it's just an arrogant brain, willing to change the world instead of helping the users. I hate THIS! I can change my own web sites, but i can't change the 100 most signifikant sites I need to view. PLEASE change this, or I must use another browser -> Yet another vote for ALT Display. (You can make the Display optional and default off, i will switch it on) BTW: Link Prefetching should be set default to OFF, we must pay traffik and so we can't recommand it to use at our work.
*** Bug 200266 has been marked as a duplicate of this bug. ***
*** Bug 201119 has been marked as a duplicate of this bug. ***
I was wondering (despite my own personal PREFERENCE that this bug shouldent be fixed *cough* bug 74241 *cough*) That the key word 4xp Should be aded to it
Mozilla 1.4 Roadmap... Based on the new Mozilla 1.4 roadmap, I'm going to retract my vote that ALT text display be in Mozilla - it belongs as a XUL Plugin, leveraging the powerful plugin architecture Mozilla provides. However, if Mozilla is going to commit to such an approach, they need to make a list of the top plugins more prominent - probably in the page that loads when install is done. Users expecting or desiring alt text Tooltips, popup blocking, etc, would all be immediately aware, that way, of how to get what they want - or keep things the way they like them.
I'm not sure if 4xp is valid either. This isn't technically a bug in Mozilla.
The bigest problem is that NO Content-Management-System Support <ALT> and <TITLE> ! Thats is the reason because big Portal Sites don&#180;t support TITLE. You have a template and there is only the ALT-Tag for an IMG but NO Box for Title. A editor can only enter the ALT-Tag. So if you want a tooltip for an Image you only can enter the ALT-Tag and Mozilla-User have loose, because it is a WONTFIX .....
Roland, can you file some Tech Evangelism bugs against the content management systems you know of with this problem? Seems like if the developers knew of the problem they could pretty easily copy the ALT field into a TITLE field with they export the HTML.
Bill: please see comment 219. copying value that is meant as ALT text into title is a wrong "fix".
Filed bug 203238 on Roland's issue.
On Bug# 203238 : Screenshots added from Macromedia Dreamweaver, and some CMS. No Title Tag in the Image-Tag-editors ! It is not possible for Webdesigner easy to edit Title-Tag, so the most can´t use this. See my Screenshots on Bug# 203238
*** Bug 205774 has been marked as a duplicate of this bug. ***
though it's not a standard, it used many web sites, and Programmers easly fix this problem. so many users feel uncomfortable because this bug. IE(up to 6), NSCP 4.x displays alt text. IT SHOULD BE FIXED. want to reopen.
This will not be fixed, as explained in comment 31. If you, as a user, use sites dependent on the alt attribute, see comment 133 or the following URI: http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en ...for various workarounds. (Comment 204 has some more.) If you, as an author, want to use alt attributes for tooltips, then your authoring style is incorrect, and you should start using the title attribute instead. The alt attribute is for alternate text, not tooltips, and using it incorrectly makes your pages inaccessible to disabled users.
Severity: minor → normal
Priority: P3 → --
Whiteboard: (SEE COMMENT 153!!!) (and 204 for workarounds) → See comments 31 (reasoning) or 285 (workarounds).
but there is only alt tag and not include title tag, alt tag must displayed tooltip instead of title. because, many users want mozilla to do. request to reopen.
Super this package http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en fix the problem with atl attribute.
Ian, It seems you & other Mozilla developers misinterpret the standards. http://www.w3.org/TR/html4/struct/objects.html#adef-alt None of the standards say: you can not display ALT text as tooltip! The goal is to help visual impaired users or text browser users, but it doesn't mean that it can not displayed for visual browsers, if TITLE attribute is not available!!!! So don't come with the explanation, that you don't want to implement because of the standards... Also your habit will not stop web developers to use inappropiate ALT texts, so visual impaired users will be not helped by this. Those webmasters who want to support visual impaired users, will support them, others can not forced by any way. So you can not affect them. Furthermore as several other comments said, nor some content management systems, nor most used web authoring tools are supporting the title attribute. Also there are many websites which are not updated anymore, but was based on ALT attribute. And the most popular & often updated example is www.CNN.com! Using the 'popupalt' workaround you suggested is not a solution, since many users even does not know that it exists! I (and as the comments shows, may other people) ask that feature for the web users who are browsing my (their) website. If I want to support both Netscape 4.x & Mozilla users too, I have to duplicate the info text used, and use it ALT & TITLE attibutes, too. I don't want duplicate content on my site! And no, javascript solutions are not fine! And it seems there are still many Netscape 4.x users. Do you guesss why??? Netscape 4,x has lighten fast bookmark feature. Mozilla bookmarks are soooo slow, that is pain to use... IMHO.
I find the work round suggestions rather patronising, this bug isnt asking for a work round.
Have you read comment 31?
What about compatibility especilly down-sides? So many pages created ago, they have alt tag that may have important essages. Standards are not answer, as you well-know about ANSI C. Many compilers follow ANSI, but they include many NON ANSI functions like graphics.h, conio.h, nested comment, etc. Many developers prefer to use getch() or bioskey() rather than gets() or scanf("%s"). [TC 2.0] We must follow standards, but we should make standards. Request to reopen. P.S. This is the oldest bug I've ever seen! P.S.2 Yes. I've read comment 31 already :)
This needs to be fixed because it's just common sense. If you really want to get strict about it, make it a preference "Display ALT text as tooltips" but default it to showing the tips. This is one example of the main reason Netscape has failed against Explorer. IE realizes that standards, while important, are not the most important. The user is. User centered applications. What a concept...
Ian, I did read Comment #31, and not fully aggree with it. MSIE, has OPTION to turn ON-OFF ALT display as tooltip. Just open Internet Options/Accessibility/ and check 'Always expand ALT text for images'. As you see even IE has such an option. Mozilla would need the same solution. Just an option. Also IE owns 95% of browser market. Mozilla is not in the position to dictate. IE gave a nice solution to users, an option. As you see comments of this "bug", many users need this feature (I don't assume it's a bug. It's more like a requested feature instead.) Mozilla developers could be so kind to implement an option in a similar way like IE has, instead of protesting against the ALT tooltip feature. Just an option, and all users would be satisfied (those who want ALT tooltips, and those who don't want it). Is that user friendly behaviour so difficult for Mozilla developers to follow?
Anyone suggesting that implementing this would increase our market share is deluding themselves. There are already many different ways of adding the feature for users who want it, see the various comments given above. Since it can't be users requesting this feature, I have to assume it is web developers, and given the number of times we have explained that the correct way of doing this is the title attribute, which also works in IE, I fail to understand why you keep requesting that this issue be reopened. > MSIE, has OPTION to turn ON-OFF ALT display as tooltip. Just open Internet > Options/Accessibility/ and check 'Always expand ALT text for images'. The option in question is totally unrelated to this issue.
He actually never suggested that it would increase mozilla usage but anyone thinking that websites will change their practices on Tool-Tips because mozilla doesn't support it is deluding themselves. I fail to see why it can't be users requesting this. It is users that can't change the website they are viewing and thus users that need this functionality. Web developers can easily fix their sites to use the TITLE attribute. It is clearly the sites that we can't edit that are the problem, ie the sites to which we are all USERS. This bug may not have a large affect on usage but it is little things like this that do turn people off from the browser.
This appears to be an issue of ideology. Some people are saying that the W3C standard uses only uses title for tooltips and that Mozilla needs to be in strict adherence to the W3C standard. Other people are saying that some users and/or web developers mistakenly but frequently expect the alt text to be displayed as a tooltip when the title attribute is not present and alt is. The point of my original comment is that this should be an option or preference. Both parties will be benefit from it. If you believe in a strict W3C browser, you can have it and if you prefer seeing the ALT text as a tooltip, you can have it too. This shouldn't be such a big deal. As for market share, I do not think nor did I say that Mozilla/Netscape can increase their market share by implementing this option. My point is that Microsoft's ideology is based on the user experience whereas W3C's standard is merely a standard (and good one at that.) MS' ideology and anti-competitive practices led to their huge market share. Ultimately, do you code by the book and satisfy some developers that can say that their program is standards compliant or do you offer a feature that is useful for the user? I personally, prefer user-centric design over standards compliance. I think users will agree and will find it easier to adopt Mozilla as a browser. Furthermore, users tend to be fickle and if they don't get what they expect (right or wrongly), they walk away with a negative impression of the product. However, don't get me wrong. Standards are very important and in this case, we can offer both so why not just implement it as an option? The guiding principle being that if there is an ideological split and the feature can be a option, make it an option for the user. The majority of web sites do not conform to the HTML standards anyway and they are not going to change either. It's easier to address it at the browser level by giving the user a choice.
Well. SHUT UP. This argument has been going for MORE THEN 2 years! Now go write a hack and shut up. *sleeps*
> It is users that can't change the website they are viewing and thus users that > need this functionality. Users who need to change this have been given NUMEROUS ways of doing it. See comment 73, comment 83, http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en , and comment 133. There is a separate bug (whose number I cannot remember off hand) asking for this to be controlled by a pref. Please move discussion about a pref to that bug. This bug is about the default behaviour. Also, our behaviour with respect to alt attributes has ALREADY caused sites to fix their markup and become more accessible. So no, I'm not deluding myself.
3rd party 'plugins' will never be the answer to mainstream issues like this, as you will see by the constant duping of this bug. what have you changed 1, 2, 3 sites? i'm sure thats extremely useful with the billions of pages out there. and what will you do when you come up against someone who doesn't want to change it or someone who you can't reach at all? trying to redesign the internet around your dreams is never going to work any more than trying to get everyone to use mozilla.
Last time Mozilla developers fixed a bug they didnt really want to fix, but more or less had to because they were pressured into it, they got there own back back by giving us a really borring splash screen, whet is this time they get there own back back by not making it a pref :o oh and *W00T* 300th comment
Trying to downtalk standards compliance in favor of user-focused applications may not get very far. There are people who would like the web to be easier to use with automated tools which they think will help users, and when keeping that in mind there are more users than just humans, and making sacrifices in user happiness now in order to pursue standards-compliance seems like an investment in greater long-term user happiness. So, sorry, for those who just want the ALTernative text to be easier to read and access, but throwing around words like User-centric won't help much in trying to argue with those pursuing Standards-compliance. Still, that's not to say that usability can't be a valid argument. I suspect that the vast majority of people who say they want an ALT tooltip probably do not care very much if the ALT text is displayed as a tooltip, they just want some easy method to read the ALT text. One line out of many text fields displayed after finding and highlighting the graphic from a list on The Media Tab under Page Info accessed by right-clicking the page, not the graphic, is a cumbersome, not to mention non-intuitive, way to check this information. There are additional valid reasons why a user may want to see ALT other than dealing with a speech-enabled browser. For example, if the graphic is so un-beautiful that it is indecipherable than even a Netscape User with good eyesight may find himself or herself having the same desire as a blind user: Wanting to read Alternative text since the graphic doesn't help. No argument for Standards Compliance on this issue states that finding this information must be cumbersome. I even proposed my own new solution: An additional (perhaps shadowed-down) layer-like display, sort of like a secondary tooltip. To the idea of using a seperate layer which does not appear to be a standard tooltip there was... no response. Speaking of no response, my roommate said I oughta read ALL the old messages before offering my own input. There were hundreds of them. I spent a day assimilating knowledge on this topic and wrote a gigantic response in article 231, pointing out both incomplete statements and logical flaws by the anti-ALT- tooltip side. To this message offering multiple counters I found... no response. (Other than one comment that the message was long, which isn't surprising considering the number of hours put into it.) It is clear that Ian Hixie is not interested in doing what can be done to satisfy the majority of people. Ian has a different agenda: Promotion of the idealogy of strict standards compliance. In pursuing this goal, the best thing to do with this thread is to either ignore the people who whine about their desires not being met or, if anything is to be done at all, educate those new to the thread by re-stating the reasons or the goals. Giving reasons seems to be enough, he has shown no interest in genuinely answering anything that questioned the reasons given. Because he continues to just re-state old arguments and not responding to problems by those who analyzed the situation, and because he never offered any response to a new idea and solution, I find that ian@hixie.ch is not serving the role of a QA Contact. Perhaps he is currently successfully sitting in that position and using its power to keep anything unwanted from happening, such as the case being re-opened or somebody getting his or her name put into the "Assigned To" field. As lousy as that may be in answering questions, this behavior may be succeeding in limiting options by those with opposing views, and therefore Ian may have the support by others that, rightly or wrongly, share his views. It may be difficult to have Ian replaced if he has the support of many senior members of the Mozilla project. More complaints on this thread, by either side, is futile. Webmaster33 continues to think that re-trying the same old opinions may help change Hixie's mind. Ain't gonna happen. Hixie may think that pointing people to post #31 will educate them and that they will overlook any of the problems with it pointed out in 231. Ain't gonna happen. Ultimately, as long as this thread continues to be maintained in the same way, not much is gonna happen. This serves the anti-ALT-tooltip viewpoint quite well.
The correct resolution to this bug is a combination of two other bugs : bug 172253 and bug 74241 ie to have it as a user pref defaulting to off that shows the alt text in the status bar along with where it shows the href attribute. with 3 bugs already on this subject i don't have the heart to open a new one for that pref request
> Ian has a different agenda: Promotion of the idealogy of strict standards > compliance. This is true. I have made no secret of this fact. > Perhaps he is currently successfully sitting in that position and using its > power to keep anything unwanted from happening, such as the case being > re-opened or somebody getting his or her name put into the "Assigned To" > field. I have no power here; the module owner (David Baron) is the guy who has the final word, and it is his word that I quoted in comment 31, and his word that I have been reiterating ever since.
In response to comment 231: > Nowhere in the standard does it say that hovering over an image absolutely > may not display the ALTernate text. That is correct. It also doesn't say that we must not display <p> elements in rows of boxes along the top of the page, or that we must not hide the contents of <div> elements, or that we must display <b> elements five times in the title bar. That doesn't mean that the behaviour being requested here is correct. There is nothing about the alt attribute that makes it appropriate for use in a tooltip. > I am sometimes willing to take the time to fill in ALT tags. When I do, I > have entered into the habit while checking my results of using mouse hovering > (tooltip-checking) to verify that the ALT tag is appropriate to the image it > is by. That is simply a request for an esoteric Web developer feature. In fact, Mozilla already supports an even better version of this feature -- right click the page, choose View Page Info, look at the Media tab, and you have very convenient access to all your images' alternate texts in one place. No need to hover over images or anything like that. If you _really_ want to hover over images, you can use one of the several methods described in previous comments to get that too. > It seems the best solution for a webmaster available now, short of using both > ALT and duplicate TITLE tags I have never seen a case where an image's alternate text and an image's title were legitimately the same (except when the image is decorative and they are both blank). The title attribute is _additional_ information, whereas the alt attribute is the same information as the src attribute. Therefore it makes no sense for them to be the same. > However, when viewing pages with broadband or locally, the images (especially > those below the first screen) may be loaded so quickly that there's not a good > chance to see the ALT tag within Mozilla. There should be no reason for a user with images enabled to want to see the alt text, since the alt text should be equivalent to the image. > Right-clicking the image and selecting properties is not, as comments #97 and > #170 suggest, a valid alternative. For one, it is just more work (if I wanted > to do lots of work, I could Alt-Tab to Notepad and carefully check the > source), but more importantly, as pointed out in Comment #98, it DOESN'T work! It does now. > I believe the opposition refusing to implement tooltips oughta provide one of > two things: An alternative, or a good reason why it shouldn't be available. > I'm not seeing either. Alternatives have been given: * For authors who want tooltips: The title attribute. * For people who want to see the alt attribute: View Page Info or Image Properties. Reasons have also been given: * It is the right thing: Alternate text is an alternative, not a caption or extra information. * It encourages authors to do the right thing. > And no, inserting JavaScript isn't a valid solution because people can't do > that on web pages that aren't theirs. Yes, they can, using Javascript Bookmarklets, as described in comment 133. > Comment #143: Netscape says they won't support ALT? Where's this? Various people, including the current module owner, work or have worked for Netscape, and have stated that this will not be fixed. > There is a desire to support users's needs, which is why the DOM's .innerHTML > property is copied from MSIE despite it not being a part of W3C > recommendations. The innerHTML property affected a significantly bigger number of pages (numbered in the millions, including many top100 sites). The alt attribute issue doesn't affect any top100 pages, and, as shown in bug 74241, doesn't really affect any pages at all. (Please feel free to give URIs of sites that actually are seriously affected by this.) > As comment #96 says, if nothing but the standards is desired, use Amaya 6.1. Amaya is a testbed browser. It is in fact one of the least standards-compliant browsers available. Mozilla holds the current position (IMHO) for most standards-compliant and standards-pedantic browser available and I intend it to remain so. >> The "alt" attribute is not extra information. It should be exactly the same >> information as the "src" attribute, but in text form instead of image form. > "Exactly"?!? If a picture is worth a thousand words and the average word is > at least 5 characters (including a space in between words), then that's 5K > worth of text within the ALT attribute! You should probably avoid taking sayings like "a picture is worth a thousand words" literally. Most pictures convey no more than a few words of information. The alternate text of an image is what you would read out if you were reading out the Web page in a presentation, for example. Sometimes, the alternate text can be a sentence or two as in: <p><img src="http://www.google.com/press/zeitgeist/mar03_browsers.gif" alt="Microsoft Internet Explorer 6.0's market share has been rising steadily since September 2001, and now has around three times more market share than the next two most popular browsers, Internet Explorer 5.0 and Internet Explorer 5.5. Other browsers have marginal market share."> </p> > A comment by the same author, in comment #61, says "Tooltips are not > equivalent to a secondary rendering of the content." Well, then what are > they? Extra information. For example, the title of a photograph, or the name of the artist. > That's exactly what the ALT tag is for: Describing, real basically, what the > graphic is (perfect both for those graphics viewers who just don't understand > what they're looking at and also those who don't understand the contents of > the graphic becaues their graphicless web browser doesn't even show the > graphic.) No, alternate text is not a description. For example, the alternate text for the following image: http://www.google.com/images/logo.gif ...is "Google", not "Google logo", nor "A blue G, a red o, a yellow o, a blue g, a green l, and a red e, written in a lightly serifed font, drawn in a 3D style with a drop shadow". On the other hand the _title_ of this image might well be "Google Logo" or "The Google logo is copyright 2003 by Google, Inc". >> I, as *a user*, am sick and tired of seeing stupid tooltips pop up everywhere >> when browsing with IE. > If you don't want to see the tooltip, why are you hovering your mouse over the > graphic without clicking? Generally, that happens just because the mouse happens to have ended up there. It isn't a conscious act. > Here is a website that uses ALT tags but which cannot be updated: > http://web.archive.org/web/20000608132336/www.zhq.com/entry/main.htm The use of alt attributes on that page is actually pretty good, and there users are not negatively affected by the lack of tooltips. > 99,1% of webpages with alt tooltips will never be corrected. I'm very sorry. 99.1% of Web pages with alt tooltips do not need to be corrected and are not affected by this issue. Let me know if I missed anything you wanted a reply to; I couldn't really follow all of the arguments in comment 231.
First, an admission of guilt. Gasp, who in their right mind would admit a mistake? As a new user of Mozilla/Bugzilla, I filed a duplicate bug by mistake because I didn't find a similar bug. That does not mean it wasn't there. I just forget if it was my query or if I simply just skipped over it in the results. When my bug was marked as a duplicate, I added a comment to this bug not realizing that there were 200+ comments on it already. My apologies. I don't like filing duplicates. Second, after reading the reasons why ALT tags shouldn't be used for tooltips, I find the arguments persuasive. HOWEVER, there is no reason to not make it an option/preference. That is what preferences are for - Some people believe one way and others believe differently. It is such trivial issue. I cannot believe that everyone has been arguing over it for two years. Just implement it as an option and set the default to disabled. So if you want it, you can enable it but the recommended or default course is disabled. This may not promote world peace but will at least allow everyone to focus on other issues. I think making it an option is covered in another bug so I will not comment further.
Hixie wrote: > There should be no reason for a user with images enabled > to want to see the alt text, since the alt text should > be equivalent to the image. I can give you a perfectly valid counter point to this one: I'm red green-green blind. Of course, typically I surf with images enabled. But when something is color coded with colors I can't differentiate, easy access to the ALT text would be a definitive plus. (OFF TOPIC: has anybody a plugin or the like to display the RGB value of the point under the mouse cursor?) Best Regards, Peter Jacobi Ceterum censeo: I'll still vote for the onpageload.js solution.
<I>[...]In fact, Mozilla already supports an even better version of this feature -- right click the page, choose View Page Info, look at the Media tab, and you have very convenient access to all your images' alternate texts in one place.[...]</I> With all due respect, that is by far the strangest definition of "convenience" I have ever seen.
>> That doesn't mean that the behaviour being requested here is correct. There is >> nothing about the alt attribute that makes it appropriate for use in a tooltip. > > The title attribute is _additional_ information, whereas the alt > attribute is the same information as the src attribute. Uh, that description of ALT is generally what tooltips are meant for. >> A comment by the same author, in comment #61, says "Tooltips are not >> equivalent to a secondary rendering of the content." Well, then what are >> they? > > Extra information. For example, the title of a photograph, or the name of the > artist. Well, I don't know what programs you've used, but what you wrote do not describe the standard I'm familiar with. My first exposure to Tooltips was Microsoft Word. They were tips that described what happened if an items on the toolbar was clicked (hence the name tooltip). If you hovered over a pair of scissors, this little layer would show up that says "Cut". The tooltip described, in text, exactly what the graphic was meant to portray. This is exactly the role you suggest ALT attributes are meant for. I generally try to use Keyboard UI's instead of Mouse UI's and therefore hardly ever even see Tooltips, preferring instead to use menu options, but I do know that this usage isn't limited to Microsoft software. Another user of this standard is the software developer Ahead Software ( http://www.ahead.de ). For example, they have a button in the main Nero program which has a tooltip of "Switches to Nero Express". This describes what the image is meant to convey: It does not get extra-verbose by describing what Nero Express is or how it differs from the mode I'm in. (In fact, to this day I don't know.) I do agree that use of ALT to add in a bunch of additional information is poor use of ALT, but the purpose of Tooltips is to inform users of exactly what the ALT text is meant to do: Provide a text description of what is being hovered over. What you've suggested describes a non-standard (and therefore, even by your own criteria, poor) use of tooltips. If a title of a photograph (frequently used as a top caption) or the name of an artist (frequently used as a bottom caption) are desired, the common place for this isn't the tool-tip, it's additional document space. Place the information above or below the graphic in question. If there is more than a line then perhaps a paragraph or a table of information could go elsewhere on the page. Extended information and/or help on a topic can be obtained by asking for it: In Windows environments this can be done by pressing F1 or clicking on the Question Mark button sometimes found to the left of the Minimize/Restore/Close buttons. I'm not suggesting that Mozilla needs an button added to the title bar in order to try to call up more information. What I am suggesting is that the standard use, found in way more than just web browsers, is that when a person hovers, the person gets a short and to-the-point text description. Any information more than that is really just being a hack of the standard. Perhaps the reason so many people disagree that ALT is bad for Tooltips isn't that the ALT attribute is being misunderstood by the pro-Tooltip people, but rather a misunderstanding (by one of us) on the proper use of Tooltips. Although I may be a non-expert in GUI's, I go by the assumption that there is a reason these informational layers became known as Tooltips instead of Caption Blurbs. That reason is, they described the graphics for the tools. And now to follow up on earlier comments: > The use of alt attributes on that page is actually pretty good, and there users > are not negatively affected by the lack of tooltips. That site, by the way, was one that I ran (before events have forced me to refer to a URL archive.org), so thanks for that compliment. (I put in every ALT attribute by hand, the original webmaster encouraged me not to waste time for such users.) While I've got the soapbox here, I should follow up on comment #303. I'm quite impressed, Ian, with the class you demonstrated in handling my earlier comment.
> With all due respect, that is by far the strangest definition of "convenience" I have ever seen. Right. In fact, I believe that in the comment he was replying to, I had detailed out that exact same procedure and I had called it "cumbersome, not to mention non-intuitive".
This is the exact issue that Ian has failed to find a valid response to. The fact that some people may not be able to determine the meaning of an image. In this situation having to right click and find the alt text through the properties screen is extremely bothersome, and even worse is the Media tab in Page Info. How are you suppose to relate which images are which when all you have is a URL, type and Alt Text. You would have to right click on every image on the page to find the URL of each image befroe you could relate it to that table, which makes it devoid of any usefulness because you can get the ALT text from the same place as the URL.
> HOWEVER, there is no reason to not make it an option/preference. There are several reasons, but that is another bug. See bug 74241 comment 35. > I'm red green-green blind. Of course, typically I surf with images enabled. > But when something is color coded with colors I can't differentiate, easy > access to the ALT text would be a definitive plus. While I sympathise with your position, I think specialist needs such as this are better served by add-on packs, of which there are several. >> [...] In fact, Mozilla already supports an even better version of this >> feature -- right click the page, choose View Page Info, look at the Media >> tab, and you have very convenient access to all your images' alternate texts >> in one place. [...] > > With all due respect, that is by far the strangest definition of "convenience" > I have ever seen. Have you tried it? The description of the feature is a lot longer than the actual use of it, and on pages where you are likely to want to check alt attributes, this is a lot easier than scrolling all the way down the page hovering over each image and trying to read the tooltip before it disappears. >> The title attribute is _additional_ information, whereas the alt >> attribute is the same information as the src attribute. > > Uh, that description of ALT is generally what tooltips are meant for. If you want to be totally accurate about this, what Mozilla shows are titletips, not tooltips. Tooltips are one or two word balloons that appear above tools. Titletips are typicially long sentences that are shown above parts of documents. > The tooltip described, in text, exactly what the graphic was meant to > portray. This is exactly the role you suggest ALT attributes are meant > for. It's certainly similar, but most Web authors are not looking for this when they try to add titletips. > If a title of a photograph (frequently used as a top caption) or the name of > an artist (frequently used as a bottom caption) are desired, the common place > for this isn't the tool-tip, it's additional document space. You are confusing two issues. On the one hand, there is the question of what information belongs in what attribute, alt and title. On the other hand, there is the question of which attribute should be shown in little bubbles. The alt attribute is alternate text, a text replacement of the image. The title attribute is for extra information. That is quite clear from the spec. So the only real question is the second one: which attribute should be shown in the balloon. We have decided on the second, since most Web authors seem to want to use the balloons for extra information unsuitable as alternate text. We have considered showing the alt attribute as well (in this bug and others) but it is our opinion that doing so encourages the use of unsuitable alternate texts, as has been explained before, e.g. in comment 31.
Also, note that the media tab shows you a preview of the picture, so you don't have to look at the URI at all.
In 1.4beta it does not
Well, betas aren't perfect, that's why they're betas. :-) It works in the nightly build I'm using.
correction: the default size of the page info window completely hides the image preview and gives no indication that it is present, thus you have no idea it exists unless you happen to resize it. even so this feature is less than useful. having to open a seperate window to define the meaning of all the links is a lot less usable than hovering over the images, because the context is usually very important. this is why when images are off ALT texts are shown in-line, and there needs to be some way to do this. the suggestion that this feature needs to be an add on is rediculous. it takes an insidnificant amount of code to implement and a single checkbox pref. there are hundreds of features in mozilla that i and most people will never use. if mozilla was some kind of slimline browser i could accept this argument. but mozilla is meant to be a suite of comprehensive internet applications. it should accomodate as many people as possible
> correction: the default size of the page info window completely hides the > image preview and gives no indication that it is present, thus you have no > idea it exists unless you happen to resize it. even so this feature is less > than useful. That's a bug then. Please file it. > having to open a seperate window to define the meaning of all the links is a > lot less usable than hovering over the images, because the context is usually > very important. Please, lot's not introduce hyperbolae here. As we've already mentioned, users don't actually need the alt attribute contents to determine the "meaning of all the links". We're only talking about an authoring help here. > this is why when images are off ALT texts are shown in-line, > and there needs to be some way to do this. You could turn the images off, that would do it... > there are hundreds of features in mozilla that i and most people will never > use. That's also a bug, and one which, through our planned shift to Firebird, we will be solving by removing those features.
"Have you tried it?" Of course. That's why I am so puzzled about your perception that this could be anything like "convenient". "The description of the feature is a lot longer than the actual use of it, " No, the actual use is far more complicated than your description. You omitted two facts: a) the correct tab "Media" has to be activated (this being the 3rd click in sequence) and you have to look through all images listed there. Have you ever looked at Page Info | Media on a news page like CNN? You have 200 or more (!) images because you not only get navigational icons and photographs but all sorts of lines, rules, rounded corners, bullets, symbols, etc. pp. all with names (Actually long long URLs) only the web designer understands, so you may end up clicking _all_ of the entries before you find the right one. _This feature is completely useless for ordinary users looking up the ALT text of an image._ It is a textbook example of the difference in perception of programmers and users and a good proof why programmers should _never_ do GUI design. Professional GUI design means that all necessary features are reachable with a maximum (!) of _two_ clicks, with the strong drive to reduced it two one or zero. On a page like CNN the Page Info | Media may take as much as five or six dozen (!) clicks, worst case being 200 clicks. That's abysmal. "and on pages where you are likely to want to check alt attributes, this is a lot easier than scrolling all the way down the page hovering over each image and trying to read the tooltip before it disappears." Absolutely not. It my perceiption of convience that I do not have to click _anything_ because my browser conveniently displays ALT next to the mouse pointer, _before_ I actually click on the button. All the pages so far where I wanted to see ALT it was because I did not understand the meaning/function some navigational graphics. In most cases, the webdesigners provided ALT with exactly the information I sought "what is this?". In IE and Netscape the browser conveniently tells me what the button will do should I choose to press it. It's a convenient help feature.
> _This feature is completely useless for ordinary users looking up the ALT text > of an image._ I never suggested this feature should be used by ordinary users. I mentioned it in the context of a Web developer wanting to check the alternate text on his own page. > All the pages so far where I wanted to see ALT it was because I did not > understand the meaning/function some navigational graphics. Can you give some URIs to these pages?
>>Please, lot's not introduce hyperbolae here. As we've already mentioned, users don't actually need the alt attribute contents to determine the "meaning of all the links". We're only talking about an authoring help here.<< Sometimes I and others do. I for one am not talking as a developer but as a user of many websites. Providing websites for you to look at is pointless because I doubt you have the same problems as me or the other people in interpreting the images. >>That's also a bug, and one which, through our planned shift to Firebird, we will be solving by removing those features.<< This bug is filed against mozilla not firebird. So if you're happier using Firebird I see no harm in adding the pref for mozilla. On a side note someone before quoted Google as having correct usage but actually they don't even use Alt tags on their news page, but only Title tags. http://news.google.com/
> Providing websites for you to look at is pointless because I doubt you have > the same problems as me or the other people in interpreting the images. Humour me. > This bug is filed against mozilla not firebird. So if you're happier using > Firebird I see no harm in adding the pref for mozilla. Firebird is about to _become_ Mozilla. The distinction is not really relevant.
In response to Comment #304 (Ian): > http://www.google.com/images/logo.gif >...is "Google", not "Google logo", nor "A blue G, a red o, a yellow o, a blue g, >a green l, and a red e, written in a lightly serifed font, drawn in a 3D style >with a drop shadow". >On the other hand the _title_ of this image might well be "Google Logo" or "The >Google logo is copyright 2003 by Google, Inc". No, you are not right! You can't decide what info the author wants to show about the image. If the author wants to show "Google logo" ALT text in place of image, then he will do that. And it's still a valid ALT text replacement of the image. Anyway, the "Google logo" ALT information may be useful for people who don't know that fact. And this should be possible to view in easy way (Image Properties is not an easy way). Image replacement ALT text should give some clue (a short info) to the visitor the image would be displayed in that place (e.g. "Google Logo"), and TITLE would give more or detailed info about that image. BUT if we don't have TITLE attribute, the image replacement ALT text may still give the visitor some clue what the image is. So in that case the "Google Logo" ALT text may be useful for him to get more info than nothing, and therefore in that case ALT text should be displayed as tooltip! This is a valid reasoning, explained from the viewpoint of the ALT attribute. I would aggree, that if Mozilla displays the ALT as tooltip, when TITLE attribute is not available, then display it in different color as an earlier comment suggested. Now the TITLE tooltips are displayed with light yellow background, the ALT tooltips may be displayed using light green or light blue background color. Your reason, that displaying ALT as tooltip will encourage usage of long ALT descriptions is not true. It it already encouraged by Netscape 4.x which was in the browser market for YEARS, and by 5.x, 6.x!!! Behaviour of Mozilla will not affect too much internet developers. Most webdevelopers are developing only IE compatible websites and are not bothering about crossbrowser compatibility. I'm one of those, who always tried to develop crossbrowser compatibility website for most popular browsers as much as possible. >I have never seen a case where an image's alternate text and an image's title >were legitimately the same The crossbrowser compatibility case is that case, when you would need to duplicate the ALT & TITLE text to give support to Netscape 4.x users too, who are still numerous on my website! I don't support the bug of Netscape 4, but I WANT to support those users who still use that fine browser. I'm one of those who still use Netscape 4 in some cases, and because bookmark usage is lighting fast. >The alt attribute issue doesn't affect any top100 pages I'm not convinced about this. Which resource do you accept as valid top100 source? URL? >> 99,1% of webpages with alt tooltips will never be corrected. I'm very sorry. >99.1% of Web pages with alt tooltips do not need to be corrected and are not >affected by this issue. You are wrong. You can not say for sure, that all those millions of sites are not affected. You can not guess original intention of millions of webmasters, if they wanted to give addition info for their visitors through ALT attribute or not!!!
Correction: "5.x, 6.x" was meant correctly: "IE 5.x, 6.x"
http://www.bbc.co.uk/radio1/chrismoyles/index.shtml?onair See the orange on red links at the top? Readable to most people but not all. http://www.bbc.co.uk/radio1/events/ See that title image on the right '2002 Events'. I couldn't read that. and thats two instances from a very well made site
Could people please note that Firebird Help makes it very easy to adjust the browser to show tooltips, so for new users this shouldn't continue to be a problem. This should make this bug more or less irrelevant to a large number of people in the future. And also, the BBC website is not well designed or built, and a bad example of almost everything.
>And also, the BBC website is not well designed or built, and a bad example >of almost everything. Simply does not matter how a website is designed. They likely have thousands of users every day. THIS MATTERS. If they would all use Mozilla, they would fail to get several quick info which was intended to have displayed for users as tooltip!!! Tim showed this page as example. There is another fine example on that page: http://www.bbc.co.uk/radio1/events/ Check the event titled "Rhythm Nation Live" on 25 May. There is a man's face. You can't know more about it. But the info is hidden in the ALT text: "Trevor Nelson live in Glasgow". There is NO title attribute, and we still know this info WAS INTENDED to be DISPLAYED. Why would want Mozilla developers deprive of user's rights to get these info in tooltips if there is no TITLE attribute available in image tag?
> If you want to be totally accurate about this, what Mozilla shows are > titletips, not tooltips. Accuracy is good. > You are confusing two issues. > there is the question of what information belongs in what attribute, > alt and title. Well, thank you for clarifying just what a titletip is for. Perhaps unusually, I had no problem understanding the proper usage of ALT, but I didn't understand the TITLE attribute. Now I see that TITLE is designed for the passing on of additional information in titletips. > So the only real question is the second one: which attribute should > be shown in the balloon. On what basis was this decision made? (I know you mentioned one, I address it later: Was there any other criteria used?) If I needed to choose between a description of the graphic, or "extra information" (as you called it), I would prefer to see information about the graphic. That is what I would expect, largely because the bubbles continue to be called Tooltips, and also because my first exposure to these bubbles were from IE and earlier Netscape versions which, like other programs such as MS Word, displayed information about the graphics. > We have decided on the second, since most Web authors seem to want > to use the balloons for extra information unsuitable as alternate > text. 'kay, now we have a problem: This is letting web designers dictate how I view the web. If the web designer goes through the proper channels, such as using JavaScript and CSS, then they are specifically requesting such finely detailed control over presentation. If, however, they are using standard content-based (not presentation-based) HTML tags then they are working with the philosophy that HTML and the WWW were designed on and which continues to get used: That philosophy is that the users/browsers get to figure out how to display the information. On such issues, the browsers should cater to the desires of the users, not focusing on the web site developers. To be consistant with other applications (including browsers and non-browsers alike) designed for my Operating System, I would expect the information displayed in the bubble to be a description of the graphic, not a bunch of extra information. In order to follow the standard for programs in the Operating Environment I am using (MS Windows), the information displayed in the Tooltip really should be the alt attribute and, very specifically, NOT TITLE. Placing extra information in these bubbles violates the standard for tooltips. People have suggested that the ALT attribute should be used as a fallback for TITLE like in Netscape 4. In this environment the TITLE attribute effectively overrides ALT in a battle for placement in the little hover-bubble. Hoever, if there was any overriding to be done (based on solid reasoning, rather than based on backwards compatibility) then it really should be the ALT tag that overrides the TITLE tag. The TITLE tag's attribute simply doesn't belong in a Tooltip. Actually, I wouldn't mind Mozilla verbosely displaying both in seperate bubbles, but given the choice between the two I would like my browser to display graphic information, not extra text. Of course, I'm just one person, and this desire of mine may not be important enough to make a change to the browser if I'm the only one who feels the same way. Oh yeah, there's this bug. And since we've lately been mentioning just what the nature of this bug is (compared to other bugs like the discussion of making a preference for the bubble), let's see just exactly what this bug is. Is it entitled "alt text does not show up in titletip area"? No, it is entitled "alt text is not displayed as a tooltip". The way this is phrased exactly describes what the ongoing problem is. I believe it should be possible for Mozilla to control the pixels in its own window, and therefore it should be possible to display BOTH the title attribute's titletips in one overlaying layer and also tooltips describing the ALT attribute's contents in a second overlaying layer. The arguments I've skimmed over on other topics seem to attack displaying ALT tags for tooltips because the arguments state that TITLE is favored, apparently trying to win the covetted bubble-space for the preferred attribute. Why be limited to such a narrow-minded paradigm that since past applications limited themself to one bubble then this is an un-conquerable limitation that must be adhered to? I believe it should be possible for Mozilla to control the pixels in its own window, and therefore it should be possible to display BOTH the title attribute's titletips in one overlaying layer and also tooltips describing the ALT attribute's contents in a second overlaying layer. If this gets to be too much information then a pref can be used to disable unwanted hover bubbles, satisfying not only the Pro-ALT group and the Pro-TITLE group but also that group that complained about having any hover text whatsoever. This bug was apparently closed because it was believed that people should be educated to use TITLE for titletips, not ALT. However, the whole discussion about encouraging web developers to use the TITLE attribute for extra information is off-topic because extra information has nothing to do with the ALT attribute, nor ought it have anything to do with tooltips. Since the reason for closing this bug was off-topic, and therefore not applicable to this bug, it should not be used as a reason for this bug to be closed. The bug should be re-opened until resolved (unless a different argument, unrelated to the off-topic TITLE reasons given before, can be given why it should be considered resolved and remain in its current state).
>> [The correct alt text for] >> http://www.google.com/images/logo.gif >> ...is "Google", not "Google logo", nor "A blue G, a red o, a yellow o, a blue >> g, a green l, and a red e, written in a lightly serifed font, drawn in a 3D >> style with a drop shadow". >> On the other hand the _title_ of this image might well be "Google Logo" or >> "The Google logo is copyright 2003 by Google, Inc". > > No, you are not right! I beg to differ. The following is considered a major text in the field of alternate text, I would recommend reading it: http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html It should explain your misunderstanding. > You can't decide what info the author wants to show about the image. That's the whole thing. Alternate text isn't "info ... about the image". It's text that is an alternative to the image. > Your reason, that displaying ALT as tooltip will encourage usage of long ALT > descriptions is not true. I didn't say anything about the length of the attribute, just the appropriateness of it. Showing alt attributes > I'm not convinced about this. Which resource do you accept as valid top100 > source? URL? Mozilla's official top100 list is: http://www.mozilla.org/quality/browser/buster/pagelist.html ...but really, any site that has multiple bugs filed about it, all by people who don't know each other and are unrelated to the maintainer, is usually considered important. > http://www.bbc.co.uk/radio1/chrismoyles/index.shtml?onair > See the orange on red links at the top? Readable to most people but not all. As I said, for users with special needs, there are several add-on packs available to solve such problems. > http://www.bbc.co.uk/radio1/events/ > See that title image on the right '2002 Events'. I couldn't read that. That's a general colour problem -- that text could just as easily be actual text, in which case alt attributes wouldn't have helped. > http://www.bbc.co.uk/radio1/events/ > Check the event titled "Rhythm Nation Live" on 25 May. > There is a man's face. You can't know more about it. But the info is hidden in > the ALT text: "Trevor Nelson live in Glasgow". That's an error on the page; that should be the title attribute contents, not the alt attribute contents. (It's pretty redundant anyway, given the number of times "Trevor Nelson", "Live", and "Glasgow" are mentioned on that page.)
>>That's a general colour problem -- that text could just as easily be actual text, in which case alt attributes wouldn't have helped.<< It's a problem with the IMAGE and so the ALTERNATE text is USEFUL to READ. The alternate text is correctly used by the page author so that people who need to can read it, so clearly people who need to SHOULD be able to read it. If it was normal text, there are other ways for people to change the font so it is readable that are fully supported in mozilla, so that wouldn't be a problem. >>As I said, for users with special needs, there are several add-on packs available to solve such problems.<< I have downloaded one of these add-ons that allow me to read the alt text, but for everyone person who does there are about 100 others who don't even know it exists. Including it in mozilla would make it available to everyone. >>...but really, any site that has multiple bugs filed about it, all by people who don't know each other and are unrelated to the maintainer, is usually considered important.<< like bug 25537 ?
>> So the only real question is the second one: which attribute should >> be shown in the balloon. > > On what basis was this decision made? (I know you mentioned one, I address it > later: Was there any other criteria used?) The decision to show the title attribute in these balloons is easy: most Web authors seem to want to use the balloons for extra information, which is what the title attribute is for. The decision to _not_ show the alt attribute in these balloons is related: we want to encourage authors _not_ to use the alt attribute for information that belongs in the title attribute. > If I needed to choose between a description of the graphic, or "extra > information" (as you called it), I would prefer to see information about the > graphic. Well that's good, since that's what we've implemented. > 'kay, now we have a problem: This is letting web designers dictate how I view > the web. I don't understand how that is the case. It seems, in fact, to be the opposite (Mozilla dictating to authors how to author for the Web). You still have full control over what gets shown in the balloons, just install an add-on or use a bookmarklet if you want to show other attributes than the title attribute. For example, you might want to show the target attribute of links in a balloon. Or the onclick attribute of buttons. > The TITLE tag's attribute simply doesn't belong in a Tooltip. I'm afraid most standards experts, including members of the HTML and CSS working groups, disagree with you. > it should be possible to display BOTH the title attribute's titletips in one > overlaying layer and also tooltips describing the ALT attribute's contents > in a second overlaying layer. This is not a good idea. If I recall correctly, some old builds of Mozilla did this (back in 1999, I think?) and I believe it was universally decided that it gave a horrible UI experience. > a pref can be used A pref for a minor issue such as this should never appear in the interface. We already have too many prefs, every additional pref increases the complexity of the UI. > encouraging web developers to use the TITLE attribute for extra > information is off-topic because extra information has nothing to do with the > ALT attribute, nor ought it have anything to do with tooltips. I could equally say that the alt attribute has nothing to do with tooltips. Are you suggesting we display the contents of <object> elements in tooltips? (<object> elements don't have an alt attribute, they instead use the element contents for that purpose. But the semantic meaning is identical.) > The bug should be re-opened until resolved (unless a different > argument, unrelated to the off-topic TITLE reasons given before, can be given > why it should be considered resolved and remain in its current state). The alt attribute is designed to be used as an alternative, when the image is not shown. There is therefore no reason to display it when the image _is_ shown. INVALID. I have to say, this bug is pretty funny. I now think I've had every possible argument put forward for showing alt attributes in tooltips: It helps authors and it hinders authors, it helps users and it hinders users, it gives too much control to the author and it gives not enough control to the author, it is presentation and it is semantic, it will encourage good behaviours and it will encourage bad behaviours, it is against the spec and it is not against the spec, it is standard behaviour and it is non-standard behaviour, we should display the alt attribute only, the title attribute only, the alt and the title attribute together, the alt and the title attribute at the same time but in separate bubbles, the alt attribute if the title attribute is missing, the title attribute if the alt attribute is missing, there should be a pref, there shouldn't be a pref, it should be the default, it shouldn't be the default, add-on packs make this bug irrelevant, add-on packs aren't enough and this bug is still relevant...
> Including it in mozilla would make it available to everyone. Including mouse gestures in Mozilla would make it available to everyone too but there are good reasons not to include those too. In the case of this bug, the reasons have been given multiple times, most eloquently in comment 31. >> ...but really, any site that has multiple bugs filed about it, all by people >> who don't know each other and are unrelated to the maintainer, is usually >> considered important. > > like bug 25537 ? As far as I can tell, no single site has been mentioned twice by unrelated people, so in fact no, not like this bug.
>Mozilla's official top100 list is: >http://www.mozilla.org/quality/browser/buster/pagelist.html Sorry, I can't accept Mozilla's carefully selected sites as top100 list. Give an independent/external source. >> http://www.bbc.co.uk/radio1/events/ >>... >> the ALT text: "Trevor Nelson live in Glasgow". >That's an error on the page; No, I don't aggree with you. It's not an error. It may not fit the standards, but it's not an error. They just want to support Netscape 4.x users, so they don't use title attribute. The 95% of the visitors are able to view that text correctly in tooltip. You can't call something an error, if it's working for 95% of the people... Only Mozilla users sucks viewing that site correctly, all other visitors are happy with the correct display in IE or Netscape 4.x. Additionally the page seems crossbrowser compatible, so it's very fine page. No error... >we want to encourage authors _not_ to use the alt attribute for information >that belongs in the title attribute. As I explained, that behaviour doesn't encourage authors to use title attribute, but unfortunately encourages users to use IE instead Mozilla... Mozilla's 1% will not encourage the other 95% to change their habit. That's funny, and very optimistic :-)
> Sorry, I can't accept Mozilla's carefully selected sites as top100 list. The "top100" list is not the list of the 100 top sites on the Web. It's Mozilla's list of sites we consider important. (It's not the "top" sites, it's not even 100 sites. "top100" is just the term we use for historical reasons.) Anyway, you asked which sites I accepted when it came to sites that Mozilla considers critical for bugs like this. I told you. If you don't accept the list there isn't much we can do about it. :-) >> That's an error on the page; > > No, I don't aggree with you. It's not an error. It may not fit the standards, > but it's not an error. By "error", that's exactly what I meant. It doesn't "fit" the standards. > As I explained, that behaviour doesn't encourage authors to use title > attribute, but unfortunately encourages users to use IE instead Mozilla... > Mozilla's 1% will not encourage the other 95% to change their habit. That's > funny, and very optimistic :-) And as I have explained, our behaviour in this and other issues has _already_ had a significant effect on both sites and other implementations (for example Konqueror specifically followed us on this issue). It also does not encourage users to use IE; in my experience, users, once exposed to Mozilla, stick with it. Our market share problem is entirely a distribution problem nowadays.
>> If I needed to choose between a description of the graphic, or "extra >> information" (as you called it), I would prefer to see information about the >> graphic. > Well that's good, since that's what we've implemented. Nay. I suppose that my sentence wasn't totally complete, I meant "information about the graphic's contents", a.k.a. the description of the graphic, and not the "extra information" telling more about whatever story the graphic uses. > Are you suggesting we display the contents of <object> elements in tooltips? No. Objects (such as MIDI files) often have plug-ins which have controls (like a STOP and PLAY button). I would expect that hovering a mouse over an object will let the object's plugin know that a mouse is over it, and it is up to the plugin to determine if and how to react to whatever is being hovered over. There's one big simple difference between objects and images? Simple, precedent. Images already have the well-known concept of tooltips which describe the contents of what the image is trying to portray. Objects don't have such a uniform UI, they each have their own custom interface. Images don't have code built into them doing something with hovering that would cause a conflict if Mozilla tried to do something. If the object is a type that gets handled by Mozilla's internal graphics viewer, than your suggestion isn't a bad idea just because doing so would add a certain degree of consistancy, but this shouldn't be done for all objects because much of an object's behavior is allowed to be determined by the object handler. > I could equally say that the alt attribute has nothing to do with tooltips. You could say whatever you like, but on what basis? If I make a 32x32 graphic with a scissors and place this above a text-entry field, the appropriate non-graphical description is "Cut" and this very same text is the common tooltip for that icon. I can continue to provide more examples, and on that basis I say the two have much to do with each other. You suggest they don't: Can you provide an example of an ALT attribute that would be inappropriate for a Tooltip? As Mozilla explores the idea of editing rich text further, the idea of having tooltips for small icons just like word processors do, is an idea that will make more and more sense. Cut, Paste, Open/upload, Save/download, Bold: I can think of numerous icons where no long explanation is needed: It will make sense for The ALT attribute and the tooltip to be one and the same. (Therefore, you'd best hope that Tooltips and TITLE attributes aren't viewed as synonymous, or else that would put a hole into the theory that it'd be rare for ALT and TITLE attributes to be identical and both appropriate.) I don't know why you would say that an ALT attribute has nothing to do with a text field containing a description of what the graphic is. > The alt attribute is designed to be used as an alternative True enough. > when the image is not shown. There is therefore no reason to display > it when the image _is_ shown. > INVALID. Your use of the word therefore speaks of a logical connection that doesn't exist. The word alternative doesn't mean that it can't be used at the same time. It's like walking into McDonald's and wanting two hamburgers for two dollars. You could pay in dollar bills: Two one dollar bills. A perfectly valid alternative is to pay in coins: Eight quarters. Both have their advantages: A dollar bill is lighter weight, quarters can be flipped for heads and tails. Graphics can be prettier, text can be more uniform in style and therefore more consistantly easy to decipher (l33t sp34k not included). You're proclaiming that once the graphic is loaded, nobody can say they have a reason to use the ALT attribute's contents because the graphical approach is already commited to and all alternatives must be shut out. To say that a person must turn off images and reload the page is like telling the guy at McDonald's that unless he has a second dollar bill, he'll have to take the first dollar bill back and pay eight quarters so that he is using only dollar bills or only quarters. Why not just accept the first dollar and four quarters? > > 'kay, now we have a problem: This is letting web designers dictate how I view > > the web. > I don't understand how that is the case. Your own statement two paragraphs up demonstrates this: > The decision [...] most Web authors seem to want [...] title. You're saying that the decision for how MY local client is handling things is being based on web developers. That means that THEY are the ones being able to excercise power. >> The TITLE tag's attribute simply doesn't belong in a Tooltip. > I'm afraid most standards experts, including members of the HTML and CSS > working groups, disagree with you. I'm afraid that you may be starting to confuse terminology again. Since comment 326 when I started talking about other programs such as MS Word I've been consistantly referring to the word Tooltip as an area (an informational layer, or "bubble") that shows a brief text description which serves as a description for the graphic being hovered over. You've said that a good TITLE attribute's content doesn't fit this description well. The HTML/CSS working groups may like titletips, but I doubt you'll find people who keep terminology straight and say that extra information should go into a field which is meant for a short description. > > a pref can be used > A pref for a minor issue such as this should never appear in the interface. > We already have too many prefs, every additional pref increases the > complexity of the UI. I say there are too few prefs. As a user, I'd rather hunt through many options of checkboxes and then eventually find what I'm looking for than any of the other options: Find documentation for a configuration file line (or Windows registry entry), or edit the source code (and find a Windows compiler), or need to search the web to download something seperate (addon/bookmarklet). If I want a simple experience, I can simply avoid clicking on buttons that say things like "Advanced Options". I'm not quite sure why you're attacking pref's here. I was saying that a pref can be used, not that it should be used: It is my understanding that there are other discussions for trying to decide further on usage of a pref or not. > > it should be possible to display BOTH the title attribute's titletips in one > > overlaying layer and also tooltips describing the ALT attribute's contents > > in a second overlaying layer. > This is not a good idea. If I recall correctly, some old builds of Mozilla > did this (back in 1999, I think?) and I believe it was universally decided > that it gave a horrible UI experience. This sounds very relevant. One horrible UI experience doesn't mean it was based on a bad idea, though. Perhaps it was a bad implementation, such as using an environment with the larger fonts common in the lower resolutions that more people used years and years ago. I could see how that'd be bad at 640x480 where the issue is compounded with difficulty in finding unused screen space to put a mouse cursor without an accidental hover. Things can look much different in 800x600, though, and with my 1280x1024 I have screen space to spare.
"That's the whole thing. Alternate text isn't "info ... about the image". It's text that is an alternative to the image." No! IMHO you got that slightly wrong. Officially, ALT is text to be displayed _instead_ of the image, for Lynx and for people surfing with images turned off. So, from a functional point of view, the image and the ALT have _the same function_. To accomplish this, they must convey the same information. But being different forms of expression, they may take different routes to that goal. So "info about the image" is _valid_ and leads to that goal. The text tells people who do not want to or are not able to see images (Lynx) what they are missing: "Mona Lisa". But since navigation these days relies more on navigational buttons crafted in Photoshop than on hyperlinked text, therefore being images, this becomes essential. The user must know which navigational functon he or she doesn't see: "Support hotline". If the image for Hotline is just a phone, then the very same (!) ALT text "Support hotline" becomes "info about the image". A phone could just as easily be the logo for the order hotline... So there is no difference between "alternative text" and "info about the image". "The decision to show the title attribute in these balloons is easy: most Web authors seem to want to use the balloons for extra information, which is what the title attribute is for." Extra information _may also_ (but doesn't necessarily have to) lead to that goal, if from the info in ALT the same message is conveyed. Good webdesign must make sure that people do not need both image and ALT (or else they leave out blind people) but it is possible (and some sites to that) to make a site that relies entirely on ALT for navigation. In the above example, an ALT text "Our support hotline is open 9-20 throghout the week" is clearly "extra info". But still it serves it's purpose: It is a stand-in if the image cannot be displayed _and_ it is "info about the image" _and_ it is "extra info". So, in conclusion, a good ALT text is _both_: Text to be used instead of the image _and_ a ultra-brief explanation of the image. Websites who use ALT for multiline lengthy info have IMHO poor design, but please do not try to influence good or bad web design by forcing your users. Leave that to tech evangelism.
If there is no reason why ALT and TITLE attributes should be the same then why do so many sites do it? eg http://www.netscape.com/ . The reason is so that people can read the ALT text using a hover, so they duplicated it in the TITLE attribute, an incorrect usage. So not allowing the display of the ALT attribute anywhere on the screen clearly encourages incorrect usage of the TITLE attribute, as can be seen on netscape.com ! There are also a huge number of sites in the top 100 that don't have correct usage as you determine it for example http://www.microsoft.com/ has 'Microsoft Home' as an ALT to an image which says 'Microsoft' http://www.webcrawler.com/info.wbcrwl/ displays 'webcrawler.com' as an ALT to 'webcrawler' http://www.excite.com/ has no ALT definitions at all http://web.icq.com/ has shows 'Click here to download ICQ!' as an alt to 'Download ICQ now in 18 languages' http://www2.warnerbros.com/web/main/index.jsp has many errors including 'Click here' and 'www.warnerbros.com' ALTs http://uk.altavista.com/ has possibly the best ALT being 'image' http://news.com.com/ 'click here', 'click here to play' Most of the top 20 sites in the top 100 have at least minor errors, some major, so clearly you cannot say that you have achieved anything in encouraging proper use of ALT and TITLE attributes, and if you want to make that claim it looks like you have a lot of websites to contact....
>> Are you suggesting we display the contents of <object> elements in tooltips? > > No. Yet the following two snippets are semantically _identical_: <object data="google-logo.png">Google</object> ...and: <img src="google-logo.png" alt="Google"> There is no difference between them. > If I make a 32x32 graphic with a scissors and place this above a text-entry > field, the appropriate non-graphical description is "Cut" and this very same > text is the common tooltip for that icon. So mark it up that way: <input type="image" src="cut.png" alt="Cut" title="Cut" onclick="..."> This is indeed a case where they are both validly the same, a case I had not come across before. > Can you provide an example of an ALT attribute that would be inappropriate > for a Tooltip? Well, there's the one I mentioned above: <img src="google-logo.png" alt="Google"> Here is another, also mentioned above: <p><img src="http://www.google.com/press/zeitgeist/mar03_browsers.gif" alt="Microsoft Internet Explorer 6.0's market share has been rising steadily since September 2001, and now has around three times more market share than the next two most popular browsers, Internet Explorer 5.0 and Internet Explorer 5.5. Other browsers have marginal market share."> </p> > You're saying that the decision for how MY local client is handling things > is being based on web developers. That means that THEY are the ones being > able to excercise power. This argument doesn't make any sense, as I explained above. You still have full control over what gets shown in the balloons, just install an add-on or use a bookmarklet if you want to show other attributes than the title attribute. For example, you might want to show the target attribute of links in a balloon. Or the onclick attribute of buttons. >> The TITLE tag's attribute simply doesn't belong in a Tooltip. > I'm afraid most standards experts, including members of the HTML and CSS > working groups, disagree with you. I'm afraid that you may be starting to confuse terminology again. Since comment 326 when I started talking about other programs such as MS Word I've been consistantly referring to the word Tooltip as an area (an informational layer, or "bubble") that shows a brief text description which serves as a description for the graphic being hovered over. Whether you call the bubble a tooltip or a titletip, standards experts unanimously agree that title attributes should be shown in them if they are specified. > I say there are too few prefs. Then install an add-on pack with extra prefs. Mozilla's UI people (of which I am not one) tell me that we have too many prefs. (Firebird has much fewer prefs.) Anyway, the idea that this should be pref controlled is another bug. >>> it should be possible to display BOTH the title attribute's titletips in one >>> overlaying layer and also tooltips describing the ALT attribute's contents >>> in a second overlaying layer. >> This is not a good idea. If I recall correctly, some old builds of Mozilla >> did this (back in 1999, I think?) and I believe it was universally decided >> that it gave a horrible UI experience. > Perhaps it was a bad implementation, such as using an environment with the > larger fonts common in the lower resolutions that more people used years > and years ago. At the time I was using 1600x1200, so I don't think that was the problem. It wasn't THAT long ago. > Officially, ALT is text to be displayed _instead_ of the image, for Lynx > and for people surfing with images turned off. > > So, from a functional point of view, the image and the ALT have _the same > function_. To accomplish this, they must convey the same information. But > being different forms of expression, they may take different routes to that > goal. So far so good. > So "info about the image" is _valid_ and leads to that goal. Rarely. > The text tells people who do not want to or are not able to see images (Lynx) > what they are missing: "Mona Lisa". No, it shouldn't tell them they are missing something. It should just be that information. In the case of a painting, the alterate text should either describe the important features of the image, if that is the role of the image, or be blank, if the image is purely decorative. In the case that the image is being used as a link to a page about the image, the title of the image may be valid. You basically have to think: If I wasn't using an image here, what text would I use instead? > If the image for Hotline is just a phone, then the very same (!) ALT text > "Support hotline" becomes "info about the image". A phone could just as > easily be the logo for the order hotline... "Support hotline" isn't information about the image. It's the meaning of the image (and thus valid alt text). Information about the image is something that applies to the image even when the image is put in another context. > So there is no difference between "alternative text" and "info about the > image". Indeed there is, although I think we have different interpretations of both. > In the above example, an ALT text "Our support hotline is open 9-20 throghout > the week" is clearly "extra info". But still it serves it's purpose: It is a > stand-in if the image cannot be displayed _and_ it is "info about the image" > _and_ it is "extra info". If the image is a phone, then that would be bad alt text. Better would be: <img src="telephone" alt="Support Hotline" title="Our support hotline is open 9-20 throghout the week"> > So, in conclusion, a good ALT text is _both_: Text to be used instead of the > image _and_ a ultra-brief explanation of the image. Alternate text doesn't have to be brief. It often isn't, in fact. > If there is no reason why ALT and TITLE attributes should be the same then why > do so many sites do it? eg http://www.netscape.com/ . That site only has three title attributes, all blank, so it doesn't seem to show what you claim it shows. > There are also a huge number of sites in the top 100 that don't have correct > usage as you determine it for example Note that incorrect usage is not the issue here -- what we need is usage that, whether correct or incorrect, leads to a crippled user experience if alt attributes are not shown as tooltips/titletips/baloons/whatever. > http://www.microsoft.com/ has 'Microsoft Home' as an ALT to an image which > says 'Microsoft' While sub-ideal, it isn't in any way crippling to Mozilla users. > http://www.webcrawler.com/info.wbcrwl/ displays 'webcrawler.com' as an ALT to > 'webcrawler' Again, not a problem to users without alt text in tooltips. Indeed, this supports the idea that we shouldn't show them since in this case, the tooltip would be pointless. > http://www.excite.com/ has no ALT definitions at all Well in that case we are rendering it exactly as we would if this bug was implemented. > http://web.icq.com/ has shows 'Click here to download ICQ!' as an alt to > 'Download ICQ now in 18 languages' That is indeed a case where it was presumably intended that the tooltip contain the alt attribute, but again, the user is none the worse for not having the tooltip. > http://www2.warnerbros.com/web/main/index.jsp has many errors including 'Click > here' and 'www.warnerbros.com' ALTs Again, this has no negative effect on our users. > http://uk.altavista.com/ has possibly the best ALT being 'image' > http://news.com.com/ 'click here', 'click here to play' Again, no negative effect.
With all due respect, you are contradicting yourself: "No, it shouldn't tell them they are missing something. It should just be that information. In the case of a painting, the alterate text should either describe the important features of the image..." "That's the whole thing. Alternate text isn't "info ... about the image". It's text that is an alternative to the image." So ALT text should "describe the important features of the image" and should at the same time not be "info about the image". That confuses me.
>>That site only has three title attributes, all blank, so it doesn't seem to show what you claim it shows.<< The HTML Source may lead you to believe so but right clicking on the following images reveals to you: 1. Top Left Netscape Logo. Title: Netscape Network 2. Top Right Mail logo. Title: Mail 3. Top Right AIM logo. Title: AIM 4. Top Right Radio logo. Title: Radio 5. Top Right Maps logo. Title: Maps Clearly the Netscape web developers are aware of this bug and have coded their site so that the Alternate meaning of the images is shown in Tooltips by duplicating it in the contents of the TITLE attribute. >>Note that incorrect usage is not the issue here -- what we need is usage that, whether correct or incorrect, leads to a crippled user experience if alt attributes are not shown as tooltips/titletips/baloons/whatever.<< You made it the issue. You are asserting that not displying alt as tooltips or in the status bar, or even in a pref will stop decent web developers from incorrect alt usage. Now clearly if many of the sites in the top 10 have incorrect usage and mozilla has not been rednering them as tooltips for years then this argument does not hold up. On the sites which have errors, many of which are minor it may not cause a problem to most users and that is why the errors persist. And the errors will persist forever. What is needed is a browser that can cope with all the errors and allow the user to configure it to cope with these errors in a way that suites them.
The important distinction is between information _about_ the image, and the information conveyed _by_ the image. Information _about_ the image is metadata (data about data), such as the author, the creation date, the title, etc. Information conveyed _by_ the image is the image itself, but as it would be given if the image was not there. The information _about_ the image is always the same. The information conveyed _by_ the image is context sensitive. For example, take an image of the Mona Lisa. I can think of at least three different ways it could be used. First, in a page talking about the painting: <h1>The Mona Lisa</h1> <p><img src="monalisa.jpg" alt="The mona lisa is a portrait painting of a woman with long brown hair sitting on a chair side on, facing the front of the image, with her left arm resting on the chair's armrest and her right hand holding her left wrist."> </p> <p>This painting is...</p> The second is as decoration, unrelated, or adding nothing, to the content: <h2>Foo</h2> <p> <img src="monalisa.jpg" alt="" class="decorative"> Foo foo foo, foo foo foo foo, foo foo. Foo foo, foo? Foo. Foo foo...</p> The third is in a list of paintings linking to pages with more information: <h1>Painting Index</h1> <ul> <li> <a href="monalisa.html"><img src="monalisa.jpg" alt="Mona Lisa"></a> </li> <li> <a href="ginevra.html"><img src="ginevra.jpg" alt="Ginevra de' Benci"></a> </li> ... </ul> In each case, the alternate text is radically different: it is not information about the image, but the information conveyed _by_ the image. The author could further add titles to each case, but it is likely than in all three cases the title would be the same: "Mona Lisa, by Leonardo da Vinci", or some variation thereon. The title would be what is appropriate for a tooltip/titletip/balloon. The alternate text is what would be appropritae to use instead of the image if the image was not usable (for whatever reason).
> The HTML Source may lead you to believe so... Ah indeed, there is some JavaScript-generated content. > Clearly the Netscape web developers are aware of this bug and have coded their > site so that the alternate meaning of the images is shown in Tooltips by > duplicating it in the contents of the TITLE attribute. Actually what's more likely is that they are aware of the opposite bug in Netscape 4.x and are working around that one. But the effect is the same, and doesn't affect our users. > You made it the issue. You are asserting that not displying alt as tooltips or > in the status bar, or even in a pref will stop decent web developers from > incorrect alt usage. Now clearly if many of the sites in the top 10 have > incorrect usage and mozilla has not been rednering them as tooltips for years > then this argument does not hold up. If it has caused even one Web developer to change his ways to make his site more accessible to non-graphical browsers, then it has been successful. That some sites _haven't_ changed isn't an argument proving that it has had no effect. We know it has had an effect because Web developers have in the past come to this bug, read the explanation, and fixed their sites.
Sorry, IMHO you keep contradicting yourself. "The important distinction is between information _about_ the image, and the information conveyed _by_ the image." In your three examples the use of ALT would be wrong according to the principles you lay out. Because you want only to have ALT convey the same information as the image itself (which btw is simply impossible), then according to your demands all three examples _must have_ the same ALT, because it's the same image in all examples. It is the metadata that is context sensitive: "What is the image good for" (photograph, decoration, hyperlink) is totally unrelated to the actual content of the image. Information on where a click on the image will lead is _metadata_. It has _nothing_ to do with the image's pixels, only with it's function: Creating a button for a link target. In contrast to that, the image's content (the pixels) is the constant here. And the pixels are the only information directly conveyed by the image. Everything else is pure interpretation by the beholder, which is context-sensitive to the cultural background of the beholder and therefore unknown to the webdesigner. In your example, where you want to have "Mona Lisa, by Leonardo da Vinci" as the TITLE and deem that "appropriate for the tooltip", I think - again, with all due respect - you misunderstood the intention of tooltips. A good tooltip is what other described with the things that Microsoft Office (and lots of other programs) do: They tell about the function. Metadata. Therefore, in your three examples, always having a tooltip that informs about the painter of Mona Lisa would be _wrong_. People want to know whether it's a photograph, just decorative, or whether it represents a hyperlink! So people _expect_ to have a tooltip that says either "Mona Lisa portrait etc.", _nothing_ or "Link to Mona Lisa Homepage" - which is exactly what your ALT texts would do - if Mozilla would only display it.
Ok, I understand what you're saying. I disagree, and think you are wrong, for the reasons I've already given, which you disagree with. I'm not sure what else to say.
>>> Are you suggesting we display the contents of <object> elements in tooltips? >> >> No. > > Yet the following two snippets are semantically _identical_: If you kept quoting until the third paragraph: >>If the object is a type that gets handled by Mozilla's internal graphics >>viewer, than your suggestion isn't a bad idea Are you trying to snag me in a trick question? If I said "Yes" to all objects, then there would be other problems. Instead I said "No" in a question asking about all objects, but I said there'd be no problem with doing this with graphics. Now you're complaining about me saying "No" to graphics. I purposefully already addressed this very specific issue. > If it has caused even one Web developer to change his ways to make his > site more accessible to non-graphical browsers, then it has been successful. The focus on the Mozilla browser's behavior should be concentrating primarily on how what it does affects users. Let the Composer group worry more about correcting standards, and producing HTML which is cleanly readable by not only machines but also humans. The Mozilla browser isn't meant to be used by machines, but rather by people who want to view pages on the WWW, and the WWW has millions of pages. If a behavior affects one developer who updates his tiny site which is only ever visited by 20 people (statistically, probably all of whom use a browser that would show ALT and so this change wouldn't have had any effect anyway), and yet the same behavior makes 50 users have a worse experience, then the browser is failing in the primary goal. > Note that incorrect usage is not the issue here -- what we need is usage that, > whether correct or incorrect, leads to a crippled user experience if alt > attributes are not shown as tooltips/titletips/baloons/whatever. What a horrible criteria for deciding how to code something. "We'll only do it if it absolutely cripples you by not doing it." I would like the software I use to strive for something better than being slightly above cripple-level. Maybe something like "providing the best user experience possible" using criteria more along the lines of "if it's better this way, do it this way". All in all, this entire issue is of minimal real importance. The reason to make ALT attributes easier to read isn't that it is critical for many sites, but rather that it is nice for many sites. It'd be nicer for users if they had this functionality than if they didn't. Somehow the discussion seems recently to have focused more on a theoretical web developers' use of an ALT attribute for a monalisa graphic than on what actual users want.
Showing tooltips for alt attributes when no title attribute is present would mean that people would never do it correctly because they would have no reason to (said in comment #31). It would also cause an inconsistency for when a title attribute is present that might throw off some developers. It takes balls to stick by your guns, but after 5 years of total chaos when it comes to standards, I'm not going to condone or support an activity that undermines them with proprietary behaviors. Since the standards are clear, they should be followed even if its not how it was done with HTML 1.0 back ten years ago. ALT has been clear since HTML 2.0 as a replacement for images, and title since 4.0. This has been said many times. Its not our fault if browser developers (even Netscape) and web developers didn't do it properly in the past. Netscape 4.x had layers, also. Layers no longer exist in Mozilla. Why should proprietary handling of ALT be any different? I don't mean to be a kill-joy, but I'd like to say, "I hate backwards compatibility". The idea of insensible backwards compatibility was started around the time of early PCs by such moronic companies as Microsoft. Backwards compatibility is fine, but there needs to be a point where people decide that something is too archaic to deserve their effort in making it backwards compatible. In 100 years, are computers going to be compatible with hard drives from the 1980s? I sure as hell hope not. If you want to plug in a 1980s hard drive on a computer in the year 2100 for some insane reason, you can design a device yourself to plug it into the new interfaces of the day. I assume the same will be true eventually for firewire ATA. There will come a day where operating systems will no longer inherently support EIDE, and you will have to pay for a 3rd party device or design one yourself if you are insane enough to want to use an EIDE drive on an operating system that no longer supports it. The other alternative is that software and hardware will become too complex because it will have to SUPPORT ANYTHING EVER PRODUCED ANY TIME IN THE PAST! I believe about 5 years is a good time to throw out backwards compatibility if it makes sense. I don't see anything wrong with asking web developers to rewrite their pages they have written the same exact way for 5 years, but is now obsolete. THIS IS THE COMPUTER INDUSTRY -- NOT THE PRINTED MEDIA INDUSTRY! I understand there is convergence, but if you want to publish on an unchanging medium, then use a printing press, or magazines. There are advantages to that, and advantages to using the web, but the web is not paper. <important/> On a side note, I do see it as a responsibility for Mozilla and Netscape to document any de-facto method of web development that is not consistent with standards and therefore is not supported by Mozilla. Something like tidy is not adequate for cleaning up the ALT attributes since it takes a human brain to re-think title and alt attributes. Perhaps people could design a tool to assist people in this process of conversion. </important> For those people that complain about your web server's disk usage being bloated by fixing this, realize that putting in a small ALT attribute is probably 30 bytes or so compared to a 1K or more image. Also, by using templates (i.e. http://template-toolkit.org/ ) you can share ALT attributes for identical images in different <img> tags. Looking at this all in a positive sense, it gives you the opportunity of a probably well-needed redevelopment of your web site. If you want consistancy between old browsers and new ones, realize -- as I said earlier -- that the web isn't a medium that contains static information, like magazines. It is UNACCEPTABLE how users are so slow in updating their browsers.. There are plenty of up-to-date standards-compatible browsers (galeon, etc) available that are toned-down in terms of memory footprint as compared to Mozilla. There is no reason you need to run Netscape 4, IE 3, the orignal mosaic, etc etc. The web archive was menti