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)

enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: rmurray, Unassigned)

References

()

Details

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

Attachments

(4 files, 1 obsolete file)

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 ago23 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 ago23 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 ago22 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: 22 years ago22 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.

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 mentioned earlier, but if you want to view pages there, then get the
old browsers. They are available on the web (i.e. http://browsers.evolt.org/ )
and there is no reason we need to be backwards-compatible with pages archived
from 1996. There is nothing wrong with having multiple versions of a browser. I,
for instance, have every version of Mozilla ever made for both Windows and
Linux. To ask us to provide quirky support for all web pages ever made is
assinine. Do you think Mozilla has millions of programmers?
"It is UNACCEPTABLE how users are so slow in updating their browsers.. "

With all due respect:
Unacceptable to _whom_ ?

Does user behaviour need approval? By _whom_?

So users are actually serving programmers, did I get that right? I always
thought it was the other way round. Being around in the industry for more than
twelve years, to me it has always been the highest priority to serve my
customers _as they like to have it done_. Because they provide for my income.
Silly me.
Netdemon, I don't want information on dead trees, they are so hard to grep.  we need to embrace standards so that information can be extracted from the files we create even decades from now.  but this isn't what this bug is about, if rendering of HTML 3.2 and earlier is broken wrt to ALT, there should be a different bug for that.  the big question is what a tooltip _is_.  IMO it should  be a textual alternative to the graphical information provided by the image, in other words what ALT contains.  TITLE is a caption, and should be presented as one.
"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."

Anyway, the "damage" is already done. Going back now would just cause more
chaos and inconsistency. Its already been 3 years since NS6.0 came out. See
fixing this issue as a chance to go back over all your web pages, as a lot of
content is probably out of date that you don't even realize. 

"Mozilla -- we will break your pages to make a point!" ;-)

Comment #288
> Ian, 
>
> It seems you & other Mozilla developers misinterpret the standards.
Hehe, I find that funny 'cause Ian is on the standards body.

Comment #292
>IE realizes that standards, while important, are not the most important.
To Micro$oft, money i$!

Comment #293
> Also IE owns 95% of browser market. Mozilla is not in the position to
dictate.
No, but we can do whatever we like.

Comment #299
> what have you changed 1, 2, 3 sites?
I believe the most important sites are the top100 sites. All others will fall
in line.

I also don't really think users care as much on this issue as web developers
do. Web developers seem to love their tooltips. Most users, I imagine, could
care less.

Re comment #305
> I cannot believe that everyone has been arguing over it for two years.
Welcome to the Mozilla community ;-) Netscape 4 and 6 used to not render the
background color of table cells without any text in it, so you had to insert a
1x1 transparent placeholder gif. That bug was open for years until it was
listed as errata in the standard, when it was summarily fixed. (bug 8113)

Re: comment 308

Hixie:
> 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 have to disagree on this point. For instance, if an image is in shades of
green and red, and someone is color blind, they might not be able to see it.
Someone mentioned this. What are users' alternatives in this case? Using the
"Properties" window is too burdensome.

bugzilla_alt_tooltips@toogam.bespin.org:
When I hover over the "Cut" button on Gnome's Gedit within Linux, it says, "Cut
the selection", while on Wordpad in Windows, it says, "Cut". I like Gnome's
approach better, but this is pretty irrelevant. You are mentioning a condition
where you have a link that is provided as an image. This is a hybrid situation
and a bit beyond the scope of just a normal image. In this case, it probably
pays to say where the link is going in the ALT text.
http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html said that in the case of
navigational icons, you should have the ALT text be the intended location they
go to. Hixie also had a good point in distinguishing between tooltips and
titletips. Perhaps for links we _want_ to display tooltips and not titletips
since we are describing functionality (in the case of a javascript: link) or
navigation. In that case, the standards are inadequate. Composer calls it a
tooltip, though. So which is it? Titletip or tooltip?

People had arguments that if no TITLE attribute is available, we could display
the ALT text. I'm sure there is a way this could be done without encouraging
people to break the standards, since towards supporting the standards in most
cases is also a valid one. This is really something that should be brought to
the newsgroups and discussed. Perhaps a line of compromise can be found, and it
would have to be agreed upon by David Baron. I don't want to give you any false
hopes, though. You will have an uphill battle.

A good compromise might be to allow a user to do a one-click toggle (with a
modifier key and mouse) between an image and its ALT text (and toggle back).
This would allow the user to see the ALT text in place of the image, and would
still preserve the proper use of the ALT attribute. It would be replaced
in-flow. This WOULD be an accessibility enhancement mainly for people with
color-blindness who still can see most images correctly.

> I say there are too few prefs.
Are you aware of hidden prefs? Most of the prefs are "hidden". Some people
(including me) agree that we have too many UI prefs. Some purists believe the
prefs should be removed totally, and that a good UI needs no prefs. I am more
realistic about this issue and realize even the best UI will be used by people
with different preferences. Therefore, I believe that _ALL_ (or practically
all) prefs should be "hidden" (i.e. needed to be manually entered in a form)
and we should just better document the hidden preferences. This is off-topic
here. See bug 195845 and the linked-to bugs from that one.

I'd like to thank Hixie for providing so much valuable information to people
and taking the time to answer questions. He showed a lot of patience. I believe
he also got a bit of a kick out of some of the comments :-)
Shouldn't this be INVALID?

I'm going to sleep now.
Whiteboard: See comments 31 (reasoning) or 285 (workarounds). → See comments 31 (reasoning) or 285 (workarounds). Also, see "Document containing a summary of bug comments"
> Unacceptable to _whom_ ?
To me! ;-)
Do you expect me to find this funny, too? I don't. Even with an emoticon I find
this rather arrogant, an expression of a programmer-centric view of the world.

You're not in a position to accept or decline user behaviour. So what do want to
do if users keep wanting features you don't like? Get rid of your users?
Brian isn't really speaking for the rest of us. :-)
ajhosking: 
You seem sucked that... The forum thread were closed, where you were forcing
usage of TITLE instead ALT. 
Why?
Because users/developers don't want to change their habits, until 95% of users
use IE, they don't have to worry about ALT tooltips...
So Mozilla developers are in a good way to make Mozilla inpopular, because
refuse to support ALT tooltips...
Otherwise IMHO Mozilla is a good browser, but until developers goes into other
way than user's wishes, and don't serve the public demand, Mozilla will not
become popular :-(
Brian `NeTDeMoN' Bober,
thanks for that attachment.

There is one thing I think was lacking from the attachment: You quoted #304 
("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.") 
without then quoting the very applicable rebuttle by Oliver in #307:

> With all due respect, that is by far the strangest definition of
> "convenience" I have ever seen.

Onward to your comments now:

> Perhaps for links we _want_ to display tooltips and not titletips
> since we are describing functionality (in the case of a javascript:
> link) or navigation.

Ugh... bad, bad idea.  This would make the issue even more confusing to people 
than it already is now.  Also, I'd like to be able to put an image on a site, 
and then later decide to turn that image into a link, and not need to worry 
about editing any IMG tags every time I insert an A tag.

Furthermore, and a stronger reason against this, is that the functionality 
you're describing is much more closely tied into the functionality of the A 
HREF tag (a link) rather than the image tag (displaying graphics).  In fact, I 
think what you're suggesting, a text description of a link, could be just as 
useful for links with textual, not graphical, descriptions.  So, why not put the
information in a link?

> Perhaps a line of compromise can be found, and it would have to
> be agreed upon by David Baron. I don't want to give you any false
> hopes, though. You will have an uphill battle.

Ah, sounds like a good name to know when planning to go into this uphill 
battle, thanks for the help.

This is not a battle I wish to fight, though.  It's not worth it.  I tried to 
point some things out in comment #231 (my big introduction), namely that I felt 
the opposition had documented their reasons and then stating the conclusions as 
if there was a logical jump from point A to point B, but that the logic used
wasn't solid.  Most often, it was simply incomplete, sounding good to those who 
wanted to believe it but it didn't have the weight of good solid logic.  The 
reasons were opinions, and the conclusions were presented as established facts 
but they were based on opinions (many of which I disagreed with).

I've been seeing a new argument silently being used though: That the use of ALT 
tooltips is in violation of several other paradigms in place, and that these 
paradigms are a good thing.  Now if I wanted to counter that argument I'd 
really need to go attack all these other decisions made on other bugs, reading
and arguing on several other threads and even getting into discussions that 
dictate the decisions made by standards bodies.  Some of this I may do anyway, 
but the ALT tooltip issue isn't alone worth investing so much of my life to.  
I'd be better off spending that much time working on creating a browser of my 
own.  Then, when my browser gains the dominant market share, fans of my 
software will support my ideals and argue my points for me :)

If there's one thing I view worth pursuing anymore, it's to make the viewing of 
the ALT attributes easier.  Even if they don't go into the tooltips, there 
should be an easier way than the complicated route currently available.  
Whether that is tooltips instead of titletips, additional secondary pop-up 
layers, image replacement, uninstallation of every plugin the browser uses, or 
some other suggestion easier than the current difficult path, something better 
should be implimented.  Ideally it will NOT involve a child window because 
closing the child window and re-opening a new one gets quite burdensome when 
trying to read the Alternate text of multiple images (and simply listing the
images requires a user to perform an unpleasant amount of matching between 
graphic-on-the-page and info-in-the-child-window).  Ideally it will not involve 
using a keyboard modifier and a mouse because that requires mouse usage:  Such 
a simple thing used by good web developers since even before HTML 2.0 should be 
supported and easily accessed with a good quick keyboard shortcut.  

> It is UNACCEPTABLE how users are so slow in updating
> their browsers..

Developers should not be trying to control the users.  The users are people, 
many of whom have little to no passion for computers and just want them to use 
them to help in whatever task they do have a passion for.  A lot of people 
don't like needing to invest time in re-educating themselves about how to use 
computers (or spending any time whatsoever in using computers unless it is 
incredibly beneficial or absolutely necessary).  Additionally, a lot of people 
don't want to (or can't) buy new computers on a frequent basis, and therefore 
upgrading hardware in order to better run newer software isn't a good (or even 
existant) option.  The same holds true for organizations that need to pay for 
computer upgrades as well as training time.

Therefore, if a person is enjoying the usage of an older software, let them be 
happy with it if they so wish to.  This refers to hardware as well as 
software.  Attract users to upgrade by offering something superior, not by 
trying to attack the current set up.

(What I find UNACCEPTABLE is the push developers are trying to make to abandon 
valid, working ways of doing things that just don't coincide with their view.  
With the possible exception of HTML 3.2 to 4.01, but I think not even in that
case, the new standards have time and time again been worse than their 
immediate predecessor.  Rather than abandoning the old methods, people should 
reject any adoption of the new standards being created by the current standards 
bodies because of the problems getting worsened with every standard.  However, 
I won't go into details of this here, now, because I just feel like detailing 
my complaints would be off-topic for this bug.)
>>If there's one thing I view worth pursuing anymore, it's to make the viewing of 
the ALT attributes easier. <<

See bug 172253 and then vote for it!
*** Bug 207299 has been marked as a duplicate of this bug. ***
Haven't read all the recent comments yet but I did notice this:

> Also, I'd like to be able to put an image on a site, and then later decide to 
> turn that image into a link, and not need to worry about editing any IMG tags 
> every time I insert an A tag.

And that's my point exactly. If we made alt attributes into tooltips, it would
(as you just admitted) change what authors would put in the alt attribute. And
if it does, then that shows that authors are not treating alt attributes correctly.
Ages and ages ago I thought that this may have been included in the part of   
Mozilla that deals with `sloppy' HTML. After all, if you publicise that   
Mozilla deals with sloppy HTML then surely this should be included ?   
  
Reading the diatribe below tells me that basically we, the users, have rubbed  
some people up the wrong way to the extent were heels have been dug in and  
nothing is being listened to, much less actioned on.  
  
Until ALL the web sites out there are completely standards compliant Mozilla  
should carry some functionality to support some known issues, of which this  
appears to be about the only one left now ! There surely has to be some sort  
of compromise for this one !! An on / off option to show `ALT: Alt Text' below  
the image, an on / off option to show the ALT text on top of the image,  
display the ALT text in the status bar, etc. etc.. If tool tipping is the fish  
bone you are choking on then use another approach !  
  
I know this hurts coder's pride (I have been one for 20 years and users are  
still the biggest pain in the bottom !) but sometimes pride needs to be  
swallowed if the program is to meet the needs of the users. Like it or not  
Mozilla has grown beyond the scope of `we only do this for ourselves' and now  
has real users. If some flexability is not shown I feel that Opera and  
Konqueror will easily fit the bill and Mozilla will become sidelined. Does any  
one know if Galeon shows ALT tags as tooltips, or does this bug (and I use the  
word intentionally) extend down to the rendering engine ?  
  
So please come on and get off your high horses ! The length of this O.R. shows  
that this is a problem that CANNOT just be left dormant.  
We only add quirks when the issue seriously breaks users' experiences on
important sites (or a great many small sites). This has been discussed above,
search for conversations that involve the term "top100".
Oliver: I am a volunteer, and I can deny to do anything I want to. I don't make
money from any users, nor have any obligation of any kind to users if I don't
consider their demands a priority. If you want me to consider your opinions as
if I owe something to you, then you can offer me and other volunteers money in
exchange for my time. I simply work on this project for enjoyment, and I see
many issues as much more important than this. Of course, when I say its
unacceptable that people don't update their browsers, its true. Why in the hell
should I volunteer my time if you aren't going to upgrade your browser? Seems
like a waste of time to me.
Oliver: I in no way disagree with you about users wanting certain features and
supplying those features because they are demanded in most cases. What I don't
like is the, "I am a user, I want a certain feature. You develop for Mozilla and
are obligated to do so." As a mostly volunteer project, where we aren't paid, it
just doesn't work that way. You have to give a valid reason to support
developers moving off of other feature requests to fullfill this one or even
move away from their beliefs of what's harmful to the web to fullfill the
request. This burden of evidence why ALT Tooltips are so needed that everyone
should drop what they are doing hasn't been met in my opinion. 

In fact, some believe that ALT tooltips would be harmful to the various focuses
of the web standards. Perhaps there isn't a clause saying you can't have ALT
tooltips, but there is the interpretation of the web standards that developers
make that says if you want to push for accessibility, you aren't going to want
to support improper use of the ALT attributes. Think of it as like the
constitution. There were no automobiles when the constitution was written, yet
there are federal laws regarding automobiles. How was that ammended to the
constitution? By studying the intent of the constitution. Of course, many will
believe the United States government has taken too much liberty in interpreting
the constitution and maybe we are guilty of the same thing when it comes to ALT
attributes, but this is really something that has no right or wrong answer, only
opinion and judgement. A lot of the criticisms are from assumptions made about
the standards based on their only partial acceptance by the browser and web
community. We can speculate about the standards being inadequate, etc etc etc,
but they seem to be good enough that we can at least give them a chance. Once
they are fully adopted, then we are in a position to criticize them. Until then,
its like saying, "I hate skydiving", when you've never done it. You can only
speculate on how skydiving is.

Some people apparently use 3rd party sites to interpret the standards for them,
incorrectly or correctly. I, on the other hand, usually look directly at the
standards themselves. I have done so since version 3.2 of HTML was written, and
I can tell you that back then it was pure hell. The reason is because there was
very little consistancy between browsers, and trying to write beyond the most
simple cross-browser page was nearly impossible. Its like trying to talk to
someone in Italian who speaks French. I really really don't want a return of
that tag soup, as Hixie called it. The standards are still not followed enough
to be criticized. 

There are limited resources in this project (developers, time, etc) and there
needs to be a priority set in what is handled and when. That doesn't mean an
issue isn't important, but it does mean that developers see others as more
important. People also don't want to work on something unless its actually going
to be accepted into the tree. I guarantee that if someone wrote a patch for this
bug, it would sit here for years. This bug is so controversial that before
anyone even thought of doing anything for this bug, it would have to be OKed by
the module owner. That's why people are told to bring it to the newsgroups.

Now, when it comes to saying that not upgrading your software is unacceptable, I
am perfectly valid in my opinion, especially when it comes to something like
browsers. If usage statistics are important, and you are using an obsolete
version of the software, you are sending a clear message to [some] web
developers that they need not support the software and they will not write
compatible web sites. Since I am a volunteer, the only really reward I get for
my work is increased usage of the software, and if this isn't happening, there
comes a point where it seems futile to continue working on the project. Luckily,
the usage of Mozilla is steadily increasing by most estimates, and for some, its
actually increasing a lot. I have started to see them talk about Mozilla on
various tech shows and even some OEM computers are shipped with Mozilla.
101355.471@compuserve.com: I don't understand how allowing an on/off for the
feature is going to be a compromise. If it defaults to off, then few will no
about the feature. If it defaults to on, then its as if we are breaking the
standards, because web developers will know that most peoplw ill have it on.
Plus, if its UI-based, it means we have to add more UI, which is something you
don't even want to suggest because it is a heated topic. That will bring this
bug from one controversial issue to two.

One option I see is for w3c to better clarify the issue of tooltips for ALT
attributes in the standard through errata. They mentioned tooltips for "title",
so why can't they also mention that tooltips are generally a bad idea for the
ALT attribute?

The other option is the 3rd party extensions, with perhaps a mention of them in
the release notes, so that people actually know they exist. In the rare case
that someone really needs to see them, they can download the extension. I don't
see how that is such a bad thing. I think most people are concerned about the
extra work involved for web developers, and the fact that people won't know the
extension exists. I'm sorry about the extra work for web developers, but perhaps
there is something we can do to make the extensions such as this one more
visible to users. Perhaps something like an extension manager with a way to
connect to different extension sites to query all possible extensions would be
one possibility.
bugzilla_alt_tooltips@toogam.bespin.org: I agree with you that HTML has become a
beast in many ways, but this is due to an increase in what people want to be
able to do on the web. It was realized quite a while ago that adding new tags
isn't the way to go, but instead separating layout and style (did I say it
right?). Another issue is that handhelds and other devices now connect to the
web, and making the assumption that everyone is running a PC with Win32 and IE
is just no longer valid. Proprietary HTML based on a GUI with certain hardware
expectations just doesn't work, and the standards have evolved to allow for more
flexibility a bit at the expense of simplicity. Of course, this only applies for
a publicly accessible page. If you are writing a web page only designed for Mac
users, then you don't have to support handhelds. An example of this is web-based
game sites, and this is where I have a bit of a problem with the HTML standards.
They seem to make the assumption that every site is for documentation and public
access when some sites are simply designed for only a small category of those on
the webs. For instance, the old DHTML frogger.

Of course, the whole mess is made a bit simpler with XML and XHTML, but the
adoption has been slow. Currently, IE doesn't properly support either standards,
and I see those as a way out of the mess caused by HTML. You might believe that
strictness makes life harder for the web developer, but it in fact makes things
easier because you have more of a predictability in terms of the browsers'
treatment of your document.

I'll venture to make another argument against backwards-compatibility when it
comes to browsers and standards. When we are trying to improve the standards,
backwards compatibility becomes at odds with simplicity in adopting those
standards because now you have 5 versions of the standards to support instead of
just 1. I understand this isn't an issue for the user, but it is one we have to
face, and it stretches our resources. If only people could realize that if they
all upgraded to the latest versions of the browsers it would make our lives
easier. I guess that's an unrealistic hope.

Anyway, I will mention Oliver's counter-argument in the next writing of the
document. I'd like to give others a chance to look it over first, though.
And why should he upgrade his browser if you don't volunteer your time in a way 
that is useful to him?

One of the biggest problems, perhaps, is people assuming that the browser is 
meant to be useful.  Netscape had a lot of market share and it aimed its 
product towards end users, taking advantage of HTML's extendability to add new 
features.  I've seen this be called Tag Soup, but there's the issue of 
usability versus organization.  Extra tags allowed for new abilities, and even 
if it is slightly less organized than creating Property Soup like CSS, it gets 
whatever job done.  Flexible, feature-ful software is going to have a lot of 
soup either way.  Web developers may appreciate greater organization as an 
additional option, but end users don't care, and end users don't benefit from a 
war where developers try to force webmasters to be more organized and 
developers remove functionality or refuse to implement what is requested.

A day came when Netscape said it's funding the Mozilla project that'll make 
Netscape 5.  It seems that the people in charge of Mozilla are enjoying their 
positions where they can control the Mozilla project the way they want, aiming 
for whatever goals they want, not caring about the gigantic dominance of MS IE, 
the negative repuation Netscape 6+ has as far as usability goes, or how well 
their actions may impact Mozilla's parent company (Netscape/AOL/Time Warner).  
I've long known that Amaya wasn't trying for any serious market share.  If 
Mozilla also has its own seperate goals, the team would benefit the world by 
making this much more well-known.  I thought the purpose Mozilla was meant to 
serve was to basically be a testbed and a public piece of development that 
would encourage involvement by the Open Source community.  The reason Netscape 
started this project was so the Netscape corporation could benefit from it.  If 
Mozilla follows the W3C standards more closely than anything else but the W3C 
standards don't lend themselves to being a popular product, and the masses are 
clamouring that what is being provided isn't what they want, then how does 
Mozilla fulfill it's purpose?  What good is it to alienate users just in order 
to stick to the beliefs of the elect few who sit on the W3C board?  If a 
standards body makes a mistake, why should the Mozilla team make end users 
suffer until it is corrected?

Sure, Netscape 6+ follows the W3C standards more closely, but people don't like 
it as much.  I, just one member of the masses, thought that one day the 
technical superiority would show its benefits and Netscape would start getting 
really popular again.  I myself was nievely looking forward to that day, 
waiting for the efforts to pay off.  How silly, though, it is to wait for 
something that will never happen as long as the Mozilla project cares more 
about making life a bit easier for caring, organized developers focused only on 
the long-term than how the project affects end users.

I'm not saying that volunteers should care about Netscape's corporate value, 
but shouldn't they keep the purpose of the product in mind?  Won't wide-spread 
usage of the product be based more on users having positive experiences rather 
than technical adherance to one interpretation on how the web oughta develop?
> If only people could realize that if they all upgraded to the latest versions 
of the browsers it would make our lives easier. I guess that's an unrealistic 
hope.

If everyone in this world would just get around to learning English than that 
would make life easier too, wouldn't it?

There was a time when everyone upgraded to the latest browser: Simple HTML 
handled by Netscape 3 and IE 3.  Things only got complicated when people tried 
to do advanced stuff: DHTML.  Now people are clamouring for support for XML, 
wishing HTML would just finally get around to dying a horrible death.

You can use handhelds all you want in trying to promote new standards, but that 
is all in all a good argument FOR backwards compaibility.  Handhelds often 
can't, and most frequently won't, upgrade their browsers.  If everyone did 
upgrade to the latest browsers, wild cheering would occur worldwide for 15 
nanoseconds before people would start wanting to develop things further, and 
you can be sure that in a year or two such support for handhelds would be 
considered futile because they are based on the "ancient XML standard which 
hasn't died its horrible death yet".

Rather than trying to control people by saying, "only speak this language", the 
best approach would be to support all sorts of standards.  Once solid code for 
the old standards has been shared publicly, it will take about 2 seconds for a 
manufacturer of a handheld to type in #include <old-std-parsing-rules.h> to 
support them both.  There's English, there's also slang, and there's l33t 
sp34k, not to mention pig latin.  An author can decide what to use.  Sure, I 
may think using DIV's shows a greater amount of intelligence, as I do formal 
English, but who am I to tell an experienced LAYERS user that I don't like his 
methods better so he shouldn't use it?

Loose interpreating may result in sloppier web pages being created.  So?  If 
they get too sloppy, they won't get visited.  Loose interpreating also lets 
more things work.  When using MS IE, there's already too many JavaScript errors 
on this web where the primary browser is MS IE.  Telling web site designers to 
straighten up is a good thing.  Increasing the number of errors I see as a user 
isn't.

So, getting back to ALT attributes here, and the accessibility argument:  If I 
were in a wheelchair (Mozilla), I'd probably prefer an elevator (TITLE) to a 
ramp (ALT).  Both may be an even better idea.  Any push being made for new 
construction sites to use elevators (TITLE) sounds like a good idea to me.  
However, there's still a lot of ramps (ALT) in this world, and I'd like to use 
those ramps that do exist.  So what if some older sites don't use ALT the way 
the HTML 4 specs suggest: I'd like to be able to use whatever is out there, and 
making a super-heavy wheelchair that a person can't push uphill (Mozilla won't 
show ALT attributes nicely) won't improve accessibility any.  If an old site 
has an ALT attribute, I just wanna see it.  And if a new place decides they 
want to build a ramp instead of an elevator, I may voice my preference, I may 
even try to educate them, but I sure ain't gonna get in that person's way of 
building a ramp.  Even if poor ramps are inferior, it sure as heck beats stairs 
(no useful ALT attribute).  And I, as a user, sure am not going to feel like 
I'm benefiting from using an extra-heavy wheelchair that can't use ramps.
I'm sorry for this silly question, but could you tell me, is Mozilla browser
supporting HTML 3.2 and HTML 3.2-sites or just only HTML 4.1.what-was-the-latest?
If it supports HTML 3.2, could you show me a tag in this version that can be
used for tooltips, and... why do you say that we must not support all the sites
written in HTML 3.2?
If not... so, in that case Mozilla is HTML 4-only browser, and users shouldn't
expect it can show properly any page except for HTML 4.1-pages, and for all
other pages they simply use a browser with HTML 3.2 support, as Internet
Explorer 5.5. We cannot expect that MS Word-viewer will show HTML 4 documents,
so we cannot expect as well that Mozilla-based browsers will show web-pages
written in HTML 3.2 (as a variant, those pages created when there were no
browsers with full HTML 4 support).
This conversation has turned from practical to theoretical, and although I don't
disagree with that I would like to mention that ALT tooltips is of dubious value
for end-users except a very small minority which can simply get the 3rd party
extension. I think as a web developer you forget that must users don't really
care about tooltips on their images. I for one don't. I browse with Netscape 6/7
and hadn't really thought about it until I came across this bug.

There are tradeoffs for everything.

> Rather than trying to control people by saying, "only speak this language", 
> the best approach would be to support all sorts of standards.  Once solid code
> for the old standards has been shared publicly, it will take about 2 seconds 
> for a manufacturer of a handheld to type in #include <old-std-parsing-rules.h>
> to support them both.  There's English, there's also slang, and there's l33t 
That's assuming perfect modularity, which we haven't achieved yet. Still, it
adds bloat to the code, and increased processing requirements for the HTML.
Besides, there is still no defined way to know if you should use HTML 4.1 or
HTML 3.2 besides the doctype which not everyone seems to care about or know
about. Its common for people to ask, "Why isn't my page looking like it should
based on HTML 4.1?" with the answer being they don't have a doctype and
obviously didn't verify their page. So how could we accomodate them if they
don't even tell us what parsing rules to use? Netscape 4.x was pretty much
(except for a bit of network code, etc) a completely different codebase than
Mozilla, and you can't just include a header file to use its parsing techniques.
I know you were speaking in a general sense, but to get technical, if you added
another header file, it would just be ignored by the compiler unless you
included it in an already used interface, which means that you have to figure
out where to add it, etc etc. The other issue is that the parsing of the browser
is not so modular yet that you can just throw in another library for another
standard written by a 3rd party and it will just work. Modularity is the goal of
most projects, but only a partial reality in most cases -- especially when you
are dealing with the current programming languages (which were designed quite a
while ago). COM allows for increased modularity, but only when the architecture
of the code is designed modularly. It appears that the coming redesign of the
codebase will have a more modular architecture. So, as of yet, its not so simple
as that, and also the more standards and parsing techniques we support, the more
processing is required and the more bloated the code gets. You don't want to
have to download a 150MB binary, do you?

Just like the study of economics, you have the wants and needs of the consumers,
which is infinite, and then you have your resources (in this case developers).
Developers have to weigh what's wanted and make decisions on what's more
prudent. Featuritis means that we have to maintain that, meaning that more time
is spent on what could be spent on other things.

I'll let Hixie discuss strict versus loose parsing, since he can probably do a
much better job. I'd just like to discuss the practical and theoretical
differnces in one of your statements:
>  Loose interpreating also lets more things work. 
Theoretically yes, practically no.

Can you still please explain what you have against this being in an extension? I
have asked that a few times already. I'd like to remind people that there has
already been 3 years worth of browsers without ALT tooltips. That can't be reversed.
To answer your question about extentions:
I wasn't ever aware of Netscape 6+ having any extentions until I came accross 
this bug.  Other than the other extentions on that same Japanese website, and 
the Java debugger thing, I'm not aware of any extentions.  If others are like 
me, they probably don't even know that Netscape supports extentions that can do 
the things I've seen.  So the biggest problem with extentions is that people 
won't know about it.  Secondly, I like to keep software that I find useful, 
storing it in directories and making CDs with useful software and so forth.  I 
like to think that if I had a webpage, I could put it on a CD and bring it to 
somebody with no or slow Internet access and install a web browser and view the 
web pages.  Extentions won't be available then, unless I put them in the 
archive, and then there's the whole pandora's box of which extentions to 
include and which extentions to not include.  They'll also need to be installed 
seperately.  All this makes it not worth the hassle.

I'd much rather Netscape's installation ask me about an ALT tooltip add-on than 
AOL icons.  Or the Viewpoint Media Player.

Your concern about what parsing rules to use is... unjustified.  First of all, 
a document without a DOCTYPE isn't valid HTML 4.01.  A document without a 
DOCTYPE isn't valid 3.2.  Therefore, documents without a DOCTYPE should be 
considered designed for an HTML 2.0 renderer since they, by specification, are 
supposed to accept input without a DOCTYPE.  A document without a DOCTYPE is 
simply not compliant to the specifications of the later standards.
Good lord, you people really need to learn how to write tersely.

I am amused to see that bugzilla_alt_tooltips' argument has now turned from the
"I need this to help write my pages well" camp to the "this is the correct thing
to do" camp and now finally to the "this hurts users because of existing badly
written pages" camp.

I am therefore forced to ask: What important pages are there where our behaviour
causes these problems?
I am still and have always been of the camp "sometimes you need to read the alt
text of an image even when the image is loaded"
I'm too.
And please, dont't say that the ways I can do it now are natural, comfortable
and easy.
"Oliver: I am a volunteer, and I can deny to do anything I want to."

I never questioned that. And I applaud you for your voluntary work. You do not
have to convince me of the benefits of Open Source and Mozilla.

"I don't make money from any users, nor have any obligation of any kind to users
if I don't consider their demands a priority."

This is IMHO a wrong perceiption, but very common in the Open Source / Free
Software scene. Legally and technically speaking you are _right_. 

Many OS/FS developers do not view their users to be customers. I will explain
why this is IMHO a terrible misunderstanding.

One of the following must be true: You are either working to do something for
_yourself_ or you are doing it for _someone else_. If you're doing it for
yourself, then you truly are your own boss in all respects. Play with anything
you like. Do anything that pleases it. Feel free to do _anything_.

If you are _not_ doing it for yourself, then you _must listen_ to those others
or you run the risk of doing things that displeases those others, and _that_ may
render your work a waste of time. Let us call those others "customers". Why
should they be called (and treated like) customers? Because they are.

Customers are not only people offering you money for your services. Customers
are simply people receiving services or products from you, no payment needed.

And of course you do have obligations to your customers. Not legally, because
you did not enter a two-way binding contract. But kind of a moral obligation.
And at the very top of those obligations is _listen to your customers_.

As I wrote, it's not a legal obligation, so legally and technically you are free
to do anything that upsets your customers. You may do so, and no one can stop
you from doing that and no one can blame yor for doing that.

But then comes the revenge from your customers: They, too (!), are not bound by
any two-way binding contract and therefore also free to do anything _they_ like.

They are free to immediately go to your competition. And in the Internet
business, where your competition is just one click away (or - as in this case -
readily built into 90 % of your customers' operating system) your customers
_will_ turn their backs on you. This is as sure as the fact that the sun rises
in the east.

So the fact that you do not have a legally binding contract with your users is
_not_ to your advantage. Rather, it's a disadvantage, and the only way to
counter this is to deliver your customers the best possible product. With the
best possible browsing experience. _By your customers' standards_, of course.

"If you want me to consider your opinions as if I owe something to you, then you
can offer me and other volunteers money in exchange for my time."

See above. It's not that your customers want _you_ do something for _them_. That
is a wrong perceiption. _You_ want something from _your customers_. You want
them to take your product (you wrote that yourself!). Then listen to them.

"I simply work on this project for enjoyment, and I see many issues as much more
important than this."

As I said, you are free to do anything. Just as your customers are free to
upgrade or not to upgrade. Or simply use the browser that comes with their OS,
hassle-free.

But, please, _if_ you only work for _your_ enjoyment, then _please_ do not
lament on your customers not sharing in your enjoyment. They want to work _with_
a browser, and most of them do not want to work _on_ a browser.

I also contribute (voluntary) work to the Mozilla project. And I make a living
with computers, networks and the Internet in general. I have installed Mozilla
on _every_ of my commercial customers' PCs and have won their hearts for the
Mozilla project. Not a single one of my customers, which range from individuals
to large companies, has before that even thought about using anything else than IE.

I convinced them to go Open Source. But so far, the majority of customers later
on called me and asked "where are the tooltips"? They _want_ that, and they
don't want to install _any_ add-on. They _expect_ this as a modern feature to be
built right into the browser. And they do not care whether it may be a
webmaster's fault. IE shows them, so it must be the browser's fault, in their
view. You cannot convince them otherwise, as much as you cannot convice all the
webmasters in total to rebuild their sites.

"Of course, when I say its unacceptable that people don't update their browsers,
its true."

No, it's not. Because the only one being in the position to accept or decline
the behaviour of users would be a superior of those users, i.e. their employer
or someone else in the position to give them orders. You're not in such a
position, and talking like you would be includes a claim of superiority.

That's arrogant.

As you are not in a position to accept or decline user behaviour, _the question
doesn't even arise_! You, of course, are perfectly free to state you don't like
what your users do. But it is not your position to grant or revoke approval of
their behaviour.

Look at it the other way:

If you lament the fact that people aren't upgrading as fast as you would like:
That's an expression of the fact that _your users_ find your product
_unacceptable_ ! Ever thought of it this way?

"Why in the hell should I volunteer my time if you aren't going to upgrade your
browser? Seems like a waste of time to me."

As I wrote, you look at the issue from the wrong end! Your question should be
"What in hell is wrong with my product if people don't want it?" If you don't
look at it this way, then indeed it's a waste of time.
"Good lord, you people really need to learn how to write tersely"

Good point, and you're right. I agree and promise to write shorter comments.

"I'm sorry for this silly question, but could you tell me, is Mozilla browser
supporting HTML 3.2 and HTML 3.2-sites or just only HTML 4.1.what-was-the-latest?"

Good point. But let's get even stricter: Why on earth should an up-to-date
browser support anything less than XHTML 1.1 (that's the latest)? Because
practically there are next to no websites that really employ current W3C
standards and I would like to predict _no_ webmaster will rewrite a site with
FRAMES to obscure CSS property thingies that no browser supports 100 %.
Also to pick up on a previous note, some quirks that do not fundamentally alter
user experience have been implemented such as bug 109843 which IMO is criminal.
favicon is not classified as a quirk, we implemented it because we thought it
was cool, not because we thought it was important for compatibility.
Oliver (okluge@kluge-digital.de) - extemely well put !!!  If Mozilla wasn't  
meant to have "customers" then why release it into the wild ? If the Mozilla  
developers aren't interested in what the customer wants then why employ  
Bugzilla and open its doors to everyone ? and if the Mozilla developers aren't  
interested in what we, the users, want how come they are still reading this  
thread ?   
  
Put the dam thing into the status bar and have done with it !!! When the mouse  
is over a link the URL doesn't pop up it appears in the status bar. This is  
different behaviour from other browsers but the information is still presented.  
Why oh why can't the same approach be taken for ALT tags ?!?!?!?!?  
  
Apple chose Konqueror for the basis for Safari, more and more small footprint  
devices are using Opera, so I guess maybe you are correct - Mozilla really  
isn't designed to be used but just tinkered around with by those with no  
interest in what happens to the code base (can't call it "product" since that  
implies "customers" and Mozilla doesn't have any of those).  
  
I have been a GUI / UI developer for some 20 years, and it still galls me  
sometimes when "customers" ask for features that "upset" my design or are just  
plain silly. But the job gets done and the users remain happy, the ORs stop  
coming in and I learn to accept the new "feature". The mature way of doing  
things, I hope, rather than stamping my feet and shouting "I wont', I wont', I  
wont'" ! Adding some support for ALT tags is not going to break Mozilla. So  
take a deep breath and JUST DO IT !!!!!!  
  
Just out of intereset - if the code was changed by someone would the changes be  
rejected ?  
I'm referring to the default requesting of favicon.ico even when the webmaster
may not want it to be requested. I agree that they are cool but only when
referenced properly as <link>s. 
You can't put it in the status bar because window.status already puts things
there. If I were module owner, I would be tempted to fix this bug simply to
appease people, which is why I'm glad I'm not module owner. :-)

Hixie: What if we did something like the following:

Tooltip: [TITLE - ALT] where the ALT got partially cutoff (followed by ellipses)
when the tooltip reached a certain size?
101355.471@compuserve.com: I already mentioned that if there were a patch
written,  I would 99.99999% guarantee it would be rejected. Before anyone writes
a patch, you need to get the module owner to agree with it in advance on such a
controversial issue, or risk wasting your time.

If a patch is submitted, and its review is accepted (but not yet a superreview),
you undoubtedly will have a lot of standards purists come out of the woodworks
that you haven't seen on this bug yet that have a lot of pull in the project
arguing that it shouldn't be accepted.

If the module owner doesn't push it through, it has little chance of being
accepted. Nevertheless, the module owner is most likely going to deal with a lot
of crap from people if this bug is fixed.
I just had another wacky idea. We could do something like this:

[Your title text here - ALT] where ALT is a link. when you mouseover the ALT
link, it brings up a second tooltip with the ALT text.

If this confuses anyone, I can explain what I mean in more detail.
Hmm, placing a link in the tooltip to switch to the other behavior.  Sounds 
good.

I think it'd be better to say [TITLE - whatever_the_title_attribute_has] so 
that people clearly understand that they are looking at the Title attribute, 
then when they hover over the blue word TITLE, which is a link, the status bar 
displays a message "Switch tooltip to ALT attribute".  If you put the word ALT 
then people might think they are looking at the ALT attribute.

Main reason I suggest putting the word "TITLE/ALT" first is a matter of user 
interface: If you put the link at the end of the tooltip then the distance from 
the mouse cursor will depend on the length of the attribute.

I'm not sure this is the best interface possible, but it sure beats what we've 
currently got.
I'm glad Hixie referenced the Flavell article (http://ppewww.ph.gla.ac.
uk/~flavell/alt/alt-text.html), which makes a good case for proper use of alt 
attributes.

Alternative text for images generally make useless tooltips.

For example, you've probably seen many pages with a menu of buttons, perhaps
with JavaScript image swapping while the mouse hovers over them. How is it
useful for the word "Download" to pop up when hovering over a button marked
Download?

Isn't it distracting for "*" to pop up when the mouse passes over a
graphical list bullet?

Or "--------" when passing over a graphical horizontal rule?

Incorrectly popping up such "alt" texts interferes with the usability of
pages. Users are better served by complying with Web standards in these cases.

The average user doesn't know what "alt" or "title" attributes are, and doesn't 
expect them to be handled any particular way. It's only Web authors who should 
know better who have such expectations.


A better solution would be to make it easy to toggle images on and off, so you 
can quickly check what the page looks like with all the alternate text. Netscape 
4.x had a toolbar button for this, and bug #61710 requests the same in Mozilla. 
Opera also has a button and an even handier keyboard shortcut: G.

A fast way to turn off images would provide more rapid access to all the 
alternative text on a page, allow users to turn off busy backgrounds that impede 
legibility, be useful for low-bandwidth connections or just accelerate load 
times when you want to get work done.
Well, maybe the race for "which browser gives the best browsing experience" may
be finished now.

Mozilla's parent, AOL, just decided to take a seven-year royalty-free license
for Internet Explorer and 750 mill. USD in exchange for dropping its lawsuit
against Microsoft. And AOL (which is the owner of Netscape) is now partner in
Microsofts future IE development.

AOLs CEO Richard Parsons is quoted everywhere that he sees no reason to drop IE,
because it runs so well. After Apple's Safari decision this is the second big
blow for Mozilla. Truly a sad day for all of us and of course for Mozilla.
Two good things come out of this. Well, one good thing, and one neutral thing
actually...

A) Netscape got mentioned in the news. That's always a good way to remind people
to go upgrade their browser.

B) They can drop Netscape, but they can't drop Mozilla.
The news is: The next upgrade for all AOL customers will definitely be IE. For
seven years to come. Mozilla just lost the biggest customer imaginable. AOL
would have been bigger than all other customers combined.

And how long can Mozilla survive should Netscape drop support for Mozilla (since
AOL is now part of Microsofts IE development) or if Netscape (as a company) gets
terminated?
As long as there are developers. Please take this to the newsgroups.
Is there another issue like this is discussion of ideology in bugzilla?
It's great idea that take these issue to newsgroup.
Comment on attachment 124628 [details]
drag into composer icon in NSCP 4.x (wrong bug)

Misplaced. Could you delete it?
Attachment #124628 - Attachment description: drag into composer icon in NSCP 4.x → drag into composer icon in NSCP 4.x
Comment on attachment 124628 [details]
drag into composer icon in NSCP 4.x (wrong bug)

This attachment is for another bug, obviously, so I'm marking it obsolete.
Attachment #124628 - Attachment description: drag into composer icon in NSCP 4.x → drag into composer icon in NSCP 4.x (wrong bug)
Attachment #124628 - Attachment is obsolete: true
Robin (in #382), Alan Flavell's page also highlights a reason why ALT-text 
being shown at the same time as the image is very useful in accessibility 
terms.  He uses some icons for navigation, including this one:
<img 
src="http://www.physics.gla.ac.uk/AIcons/RButtons/house_dog.gif"
alt="PPE&nbsp;Research&nbsp;Group">

somehow the image (which is of some sort of Dog house) is an approriate 
alternative to the the text "PPE Research Group", something which I can't 
understand from that image, and because of that I need rapid access to the ALT 
text, in my browser, I get ALT+title (if they're different and available etc.) 
in Mozilla I'm not given that option.

The current version of AJF's page is fine though in Mozilla (since the ALT is a 
duplicate of the parent A element which has the identical title) however a 
previous version was not (see usenet discussion in ciwah) The barriers put 
between me and the alt text of an image is one of the reasons why Mozilla is 
not a browser I can use.  It's fine it's a wontfix, you don't have to be a 
browser for all people, but please don't say that choice only has a positive 
side. It makes pages by some of the most accessible authors about inaccessible 
to some of us.
Jim: As mentioned before in this bug, for the minority of developers, power
users, or users with other special needs that, for whatever reason, need alt
attributes to be shown as tooltips, there are various extensions that have been
made and that are very easily installed.
I don't really see, now that I think about it, why allowing someone to quickly 
toggle the tooltip to show the alt text, or a portion of it, would be so bad. 
Could we have a key modifier that let you switch, like ALT + hover? Perhaps 
changing it to green wouldn't be a bad idea so people know the difference.

Hixie: Do you think something like this is reasonable?
We already have that: just use the bookmarklet mentioned above.
Along with the fact that most users don't know 'extensions' exist, the fact that
many extensions are buggy and unreliable makes them highly undesirable. It is
interesting to note that in one of my recent mozilla upgrades several of my
'extensions' completely borked up and a lot of functionality of the browser was
completely disabled. This is with only a few 'extensions' installed. Take a
moment to imagine what will happen when most of the functionality of mozilla is
switched to so called 'extensions'. 'extensions' are not a magical solution to
this problem as they have a large amount of problems in themselves. 
> The current version of AJF's page is fine though in Mozilla (since the ALT
> is a duplicate of the parent A element which has the identical title) however
> a previous version was not (see usenet discussion in ciwah) 

Haven't seen the usenet discussion. If such a document about accessibility would
had such an issue, that's pretty ironic. The only source I've seen is the
version that reads:

<a title="PPE Research Group Home" href="/"><img 
src="http://www.physics.gla.ac.uk/AIcons/RButtons/house_dog.gif"
alt="PPE&nbsp;Research&nbsp;Group"></a>

It is a poor icon choice. "Home" would be better alternate text in this context,
following "Up", "More", and "Next". A rel="home" on the <a> would be helpful too.
I had a chance to talk to some of my customers lately and I used the opportunity
to ask them about extensions. Result of this quick poll:

None of my customers was aware of the existence of extensions to Mozilla.

When explicitely asked the majority replied "ah, you mean plug-ins!". When
further asked about this the majority asked for a download function in Mozilla
to get those extra features in a convenient fashion from a one-stop-shop like
Netscape's plug-in central.

Also they knew that Mozilla's appearence can be altered with the IMHO ill-named
themes. People refer to this feature as "skins", ever since Win-Amp made this
popular.

No one ever heard the term "bookmarklet". My customers are not all computer
illiterate. Some of them deserve to be called experienced. But these things were
completely unknown to them.

When asked about a feature to display tooltips in a similiar fashion than IE
handles this they replied that they would expect to find this in Edit |
Preferences, as they expect to find every possible pref there. The fact that
there are additional prefs that need a text editor to set was also completely
unknown.
That's the whole thing. If we want new users, we have to make the transition
easy for them.

Autoscroll is another thing offered in an extension, but most people won't know
where to find it, so they think Mozilla doesn't offer it.

I really think we should at least think about making extensions more accessible
and maybe even mention them on the start page of Mozilla if we aren't going to
implement something like this bug.

Is there a bug about mentioning extensions on the start page?
*** Bug 209219 has been marked as a duplicate of this bug. ***
*** Bug 209353 has been marked as a duplicate of this bug. ***
The change indicated in this bug report is NOT contrary to the current HTML
standard.  In the HTML 4.01 Specification, terms such as "must", "must not",
"should", and "should not" are defined per RFC 2119.  RFC 2119 says (Section 6)
that:

"Imperatives of the type defined in this memo must be used with care and
sparingly.  In particular, they MUST only be used where it is actually required
for interoperation or to limit behavior which has potential for causing harm
(e.g., limiting retransmisssions)  For example, they must not be used to try to
impose a particular method on implementors where the method is not required for
interoperability."  

Providing tool-tips for the ALT text neither impairs interoperability nor causes
harm.  Thus, this feature would indeed within the HTML 4.01 Specification. 
Absent a conflicting TITLE attribute, the ALT attribute should indeed present a
tool-tip.  
The imperative in the HTML 4.01 standard is, "User agents must render alternate
text when they cannot support images, they cannot support a certain image type
or when they are configured not to display images." It only mandates that the
alternate text be rendered when the image is not. Indeed, this mandate does no
harm and furthers the goal of interoperability.

The alternate text is meant to be rendered in place of the image when it is not,
but it is not disallowed to render both at once. Who said it was?

Popping up "*" over graphical list bullets or "----" over graphical rules may
impair usability a little, but I wouldn't characterize that as "harm", just
redundant and useless. "title" is better suited for this sort of pop-up text,
and Mozilla already does that.


David E. Ross's comment #3 in bug #209353 has persuaded me that this is an
enhancement request, not a bug. Accordingly, setting Severity to "enhancement".
Severity: normal → enhancement
*** Bug 209353 has been marked as a duplicate of this bug. ***
Reference Comment #402:
Now that Severity is "enhancement" and RFC 2119 indicates this change is allowed
within the constraints of the HTML 4.01 Specification, will the
Status/Resolution be changed from "VERIFIED WONTFIX" to "ASSIGNED" or "NEW"?
The status will stay Verified Wontfix until the all the following preconditions
are satisfied:
1) A developer agrees to handle this
2) Module owner or a set of strong hackers agrees on a compromise for a method
to do this without making people abuse the ALT for things that should go in TITLE.

By the way, Microsoft just vowed to make Frontpage more standards-compliant. I
think this would be the time to maybe bring up this issue with them on the w3c
mailing list if anyone here subscribes to it. Doing so could go a long way in
diluting this issue.

I really think we should just work on making extensions (such as the one for alt
titletips) more obvious and accessible than trying to fix this questionable
enhancement request within the actual mozilla code.

There is a bug on having a tutorial/walkthrough for Mozilla (bug 74338) and I
think its important to mention extensions within it.

There is also a bug for a web-based way to get mozilla patches/extensions
similiar to Windows Update (bug 51998).

Instead of bloating the hell out of Mozilla with featuritis, why don't we move
to the idea a more extension-based infrastructure like Firebird is supposed to
have? That means we need interoperability of extensions (i.e. one extension
shouldn't be able to kill another), and exposure/transparency of what extensions
exist, perhaps with a CGI listing page on the Mozilla site a la bug 51998.
*** Bug 209589 has been marked as a duplicate of this bug. ***
Brian 'NeTDeMoN' Bober writes:
> 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.

The great majority of handheld browsers (and TTY browsers too, for that matter)
support only HTML 3.2, because it's lightweight and easy to implement relative
to all of HTML 4 + CSS.  At the time I started authoring my site, browser
support for HTML 4 and CSS was so hit-and-miss that HTML 3.2 was the clear
choice for a consistent user experience.  Since that time, I haven't seen a
convincing reason to rewrite all my pages.  

Indeed I want my site to render properly on those handheld browsers.  The Palm
OS browser I use which supports tooltips, Xiino, supports them only for the ALT
attribute, not the TITLE attribute -- naturally; it's an HTML 3.2 browser.  My
pages all have a link in the footer to validator.w3.org which you can use to
verify that they are compliant HTML 3.2.  Therefore, I can't throw on additional
TITLE attributes just to support Mozilla and Netscape 6-7.  And no, I don't
think it's realistic to expect me to maintain two separate copies of each of my
pages so that image tooltips will work in Mozilla-based browsers.

Luckily it's not a huge issue for my site because for accessibility reasons I
have authored it to avoid purely graphical navigation when possible. 
Unfortunately there are plenty of sites out there where this isn't the case.  To
name just a single example, forums such as
http://www.creativecow.net/index.php?forumid=24 use multiple icons for
navigation / mode-switching whose purpose is probably unclear the first time you
see them.  Each has ALT text which the web authors expect to appear as a tooltip
so you can learn what the icons do.  That text is equally applicable in the case
that the graphic isn't shown at all and as a clarifier when the graphic is
shown.  The claim that ALT text and tooltip text should almost never be the same
thing is absurd, and ignores the ultra-common case of images used for navigation.

> I'd like to remind people that there has
> already been 3 years worth of browsers without ALT tooltips.

And yet the vast majority of sites still have only ALT attributes (if anything),
not TITLE attributes.  Perhaps this particular crusade isn't having enough of an
effect to justify losing more users over.

Added my vote for this bug.
A user visits a website with navigation/mode-switching icons with no clear
purpose, without titles that pop up to identify them. There's no indication that
that misused alternate text is there to explain them. Which is more likely to
lose the user: the compliant browser or the unusable website?

Let's take a look how the alternate text on that Creative Cow site you mention
reads in lynx, with no mouse:

            [byte]
           Edition3
            [byte]
      Particle Illusion 3
            [byte]

IFRAME: http://www.creativecow.net/cgi-bin/advertpro/banners.pl?name=8
                                 Click for more Canon GL2 information

   * click to view thread Animating signatures by Lee on June 23, 2003
     at 08:50 gmt
   * click to view thread Anyone used a Extigy for 5.1
     realtime preview? by Byron on June 23, 2003 at 05:21 gmt


This is exactly the sort of ALT abuse we don't want to encourage.

I don't why upgrading from valid HTML 3.2 to 4.0 should be a big deal. If you
want the tooltips, just change the !DOCTYPE and add title attributes. If you
don't really need them, stick to 3.2. That's your decision as a page author. But
the browser isn't broke because HTML 3.2 doesn't do tooltips.
"This is exactly the sort of ALT abuse we don't want to encourage."

The job of a browser is to display the Web, as imperfect as it is. It is _not_
the browser's job to teach webmasters lessons.
> The job of a browser is to display the Web, as imperfect as it is. It is _not_
> the browser's job to teach webmasters lessons.

I think that when a webpage is broken, it's not the browser's job to fix it.

We don't have to educate the webmasters. They can learn for themselves that alt
text doesn't show up as a tooltips in Internet Explorer 5 for the Mac, Netscape
6-7, Mozilla, Opera 6-7, Konqueror, Safari, or iCab.

Usability aside, any web designer who expects alt text to be a pop-up nowadays
is writing their pages only for IE6/Win and outdated browsers. (They shouldn't
count on it in IE6/Win either, since the user may have turned "Always expand alt
text" off in the Advanced options tab.)
Filed bug 210383 - Mozilla should support older HTML standards/doctypes.
Robin Lionheart writes:
> This is exactly the sort of ALT abuse we don't want to encourage.

You sure are quick to leap up and scream "ALT abuse!  ALT abuse!".  Except for a
couple of banner ads, whose ALT text is no doubt specified by the advertisers,
the page uses ALT attributes in a completely reasonable way.  The four buttons I
was talking about have ALT text of "Date View", "Thread View", "Summary View",
and "click to view thread".  Yeah, "click" is discouraged because it suggests a
WIMP-browser-centric world view, but otherwise, those ALT attributes are exactly
what you'd want to see both in lynx and as a tooltip in Mozilla.

> I don't why upgrading from valid HTML 3.2 to 4.0 should be a big deal. If you
> want the tooltips, just change the !DOCTYPE and add title attributes.

That's beyond the capabilities of most web authors.  Yes, I could do it, but I
wouldn't be able to use the "Validated HTML 3.2" links in my footers to
validator.w3.org, and those are important to me (I'm a serious proponent of web
standards, but unlike you, I'm not under the illusion that showing ALT tags as
tooltips if there's no TITLE attribute is against the language or spirit of
those standards).

> But the browser isn't broke because HTML 3.2 doesn't do tooltips.

That's just the point -- HTML 3.2 _has_ traditionally had ALT text tooltips in
both Netscape and Internet Explorer.

> They shouldn't count on it in IE6/Win either, since the user may have turned 
> "Always expand alt text" off in the Advanced options tab.

As has been previously mentioned, that option doesn't turn off ALT text
tooltips.  That box is unchecked by default and the tooltips come up just fine.
"I think that when a webpage is broken, it's not the browser's job to fix it."

Of course not. But it definitely is the browser's job to display the broken page
in the best possible manner. And by the way, a page with ALT texts isn't broken.

"We don't have to educate the webmasters."

No, but some Mozilla developers want to teach them lessons on "proper HTML".
Some want to "evangelize" webmasters. It's a whole paternalistic view of the
world. That turns people _away_ from Mozilla.

"Usability aside, any web designer who expects alt text to be a pop-up nowadays
is writing their pages only for IE6/Win and outdated browsers"

Do you realize that "only for IE6/Win" means that they are creating their pages
for more than 90% of all browsers? I do not understand the use of the word
"only". That suggests that they create pages only for a minority, while in
reality it is the _vast_ majority... They only _have to_ create pages for IE6.

The browsers who do not show ALT tooltips simply have become _irrelevant_.

Apple has turned its back on Mozilla, and so has AOL. Of course that raises the
question of the future of the Netscape company. Why should AOL keep Netscape
alive when Netscape is no longer needed to develop an alternative browser?

AOL's CEO says that he sees no need to drop IE. And why? "Because it runs so
well". Ever thought about that? IE _runs_. It doesn't teach anyone anything. It
does it's job. That's all a browser should do.

How many more customers does Mozilla have to lose before it is broadly
understood that real people just want to surf the real Internet and not be
taught lessons on proper HTML?
Comment #413:
Thanks, Oliver.
Very well, said. Better than I could ever say:
"Ever thought about that? IE _runs_. It doesn't teach anyone anything. It
does it's job. That's all a browser should do."

>How many more customers does Mozilla have to lose before it is broadly
>understood that real people just want to surf the real Internet and not be
>taught lessons on proper HTML?

The truth is, that it seems Mozilla developers are developing Mozilla for
themself, not for the public :-( They are not interested to make Mozilla
popular... :(((

Webmaster33
>Some want to "evangelize" webmasters. It's a whole paternalistic view of the
>world. That turns people _away_ from Mozilla.

Ah. So all those Tech Evangelism bugs marked FIXED are a figment of my
imagination, because people get angry when you help them fix your site? Please
take your nonsensical ramblings to alt.dev.null, where they can meet the
reception they so richly deserve.
I think that the problem is that the web is a community, and not a government. 
We can't tell authors how to design their sites. The w3c recommendations are 
there to provide a common ground for both web authors and browser developers 
so that we can have predictable behavior. The problem is if the w3c 
recommendations are considered immutable. They are not immutable, and should 
be discussed and improved upon, and I really think you should never consider 
them 100% complete (although its pretty stable at the moment). The idea that 
10 years from now they will be identical makes me laugh. The web authors' 
parts are to report inconsistancies or ambiguities in the standards, and the 
w3c should take these into consideration. The authors are confronting the 
standards from a practical aspect, while the w3c committee members are 
confronting it from an engineering aspect. If they will not take into account 
the actual results of various portions of the standards and change them when 
necessary, then the standards will become obsolete and ignored. 

The inconsistancy in the standard is there is nothing saying that ALT should 
NOT be shown as a tooltip, yet that's what Ian Hickson is saying is the 
correct behavior, and I agree. So why isn't it in the standard? ALT is 
obviously not correct, and a note should be there. Also, more extensive 
examples should be in the standard of proper usage for the attributes. I sent 
an email to the w3c mailing lists asking to clarify that portion of the 
recommendations. I feel that if the ambiguity is removed, then people will 
KNOW Mozilla's behavior is correct, and there will be no argument. 
http://lists.w3.org/Archives/Public/www-html/2003Jun/0106.html
"Ah. So all those Tech Evangelism bugs marked FIXED are a figment of my
imagination, because people get angry when you help them fix your site?"

When developers help webmasters fix pages that are actually broken that is okay
and I applaud developers who take the time to do that. But I do not like the
paternalistic view _some_ developers have that they can read the standards
better than webmasters can read them. This _is _ paternalistic. ALT tooltips are
not forbidden by the standards, despite all claims of the contrary.

Some developers don't listen to their users (customers!) and just insist in
their view of the standards (and the world). Just look at the number of dupes
this bug has! I dare to say this is _the_ bug with the most duplicates. But this
does not mean users are so dumb that they just file identical bugs.

Obviously a large number of users think of this as a bug that needs fixing!

And yes, I can understand that some webmasters do get angry when they took
effort to created a site that gives IE users (the vast majority) the best
possible experience and even spent extra time so NS 4 users have an adequate
experience. So for > 95% of all users the web site works just fine. Then comes a
fraction with 1% market share and cries "Improper HTML! You have to fix that so
that we can view your site, too!". Technically, they may be right in many cases.
But does it make (economical) sense to recreate the site for them? No! Ever
looked at it this way?

"Please take your nonsensical ramblings to alt.dev.null, where they can meet the
reception they so richly deserve."

Please try not to get personal.
Here are some other useful links from the mailing list archives. Notice the 
argument that the specs should still be more specific even was discussed as 
early as 1998:

http://lists.w3.org/Archives/Public/www-html/1998Jan/0125.html
http://lists.w3.org/Archives/Public/www-html/1998Jan/0164.html (From Hixie :-)
http://lists.w3.org/Archives/Public/www-html/1998Jan/0171.html

I really would like to see an explicit mention in the specs that ALT tooltips 
is inappropriate and then we can lay this issue to rest.

"I really would like to see an explicit mention in the specs that ALT tooltips 
is inappropriate and then we can lay this issue to rest."

I doubt this would settle the issue. Technically yes, a change in standards
would suggest that the bug becomes INVALID.

But a change in specs doesn't change one iota of the Web's reality.

So the issue would remain. There are some things in the real Web that are done
beyond the standards. Some even have to be done in violation of the standards. 

For instance, HTML 4.01 does not allow to have frames with 0 pixel distance
between them. Since almost every graphical website UI needs this feature,
webmasters use tags like FRAMEBORDER from proprietary Netscape HTML that _all_
browsers understand. Even Mozilla. And even in standards-compliant mode, despite
that fact that it is not covered by HTML 4.01 (isn't that a violation of the
definition of the compliance mode? ;-)
Huh? Most graphical sites don't use frames, and I'm glad because they are evil.
"If they will not take into account the actual results of various portions of
the standards and change them when necessary, then the standards will become
obsolete and ignored."

Wise words! But I fear this has already happened, and the Microsoft corporation
may erode standards further. Understand me right, I am very much in favour of
universal standards that make data exchange (and data representation) so much
easier!

But HTML 4.01 is now six years old, and still W3C and IETF have not fixed the
(IMHO) bug that TABLEs have a WIDTH, but no HEIGHT! Forcing webmasters to either
resort to the (proprietary, but widely accepted) HEIGHT tag or to CSS properties
that are poorly implemented in many user agents does not make things better. 

Also, the W3C does not present a "reference browser" that would be the benchmark
for all user agents that shows everyone how it has to be done. No, Amaya is no
reference. Even W3Cs own browser doesn't implement all things the W3C comes up with.

As much as I would be willing to fight for effective standards, I have to
realize that they are an idealistic dream. At least for the moment. If the W3C
thinks that all webmasters around the world will entirely re-write their FRAMES
using websites to entirely different XHTML construct, think again.

Btw, why do you think frames are evil? Because they have been invented by
Netscape? They make great navigational constructs and are very easy to program.
Contrary to the XHTML construct. 
Why frames suck -> http://www.cablesandconnectors.com/

I'm a good customer of the author of this site, and he's a great guy, but he did
give an example of why frames can be nasty :-)

He knows that it would look better without frames, but since his site isn't CGI,
but generated HTML using a Qbasic program, frames suited his purpose just fine,
and he doesn't really care much about how it looks, just that it works.
The arguments on both sides trouble me.  

Those who demand flexibility do not understand standards.  To the extent it is
explicit, a standard must be followed (a principle that Microsoft does not yet
understand).  It is not merely a suggestion; instead, it is a way for unrelated
components (e.g., your browser and my Web page) to work together.  Further, we
should not jump to change a standard; otherwise, we risk breaking something that
currently works.  

On the other hand, the purists who resort to defending their position by
referring to the HTML 4.01 Specification (which should be treated as a standard)
have not read it carefully.  As I (and several others) pointed out before, the
Specification does not prohibit displaying tooltips for ALT.  The Specification
does say how such words as "must" and "should not" are to be interpreted by
referring to RFC 2119.  A simple reading of RFC 2119 clearly indicates that the
absence of any prohibition or recommendation against displaying a tooltip for
ALT means that such a display would indeed be allowed by the Specification since
such a display would neither impair interoperability nor cause harm.  

Denouncing those with opposing opinions as "spammers" is really not very
helpful.  Such slurs have appeared in several comments on this bug.  I have also
receive E-mail libling me with that term.  I am neither a spammer nor a troll. 
I am a software professional, about to retire after 41 years of experience (over
 30 as a software test engineer).  I had thought of volunteering my talents as a
Mozilla tester, both executing others' tests and designing new tests.  However,
if my efforts will only lead to rudenss and insults, I have too many other
volunteer opportunities to subject myself to such stress.  
Unbeleivable.  I had high hopes for the open source community, but this
discussion seems to be moving avay from discussing a solution...
1) ALT _has_ been used for "tooltip" text in IMG icons.
2) TITLE _should_ be used.
3) Would this Mozilla "feature" force every person that has used ALT instead of
TITLE to make changes in their HTML pages?  I do not think this is feasible,
especially since the market leader IE, does this flawlessly.
SUGGESTION:
3) If only TITLE or ALT is available, show text as tooltip.
If both ALT and TITLE is available, show title text as tooltip.
424> I do not think this is feasible, especially since the market leader
424> IE, does this flawlessly.

To some, those flawless alt tooltips are themselves a flaw in IE. Personally,
I disliked writing things like <img src="hr.gif" alt="---------" title="">
to discourage IE from producing annoying popups.


413> They only _have to_ create pages for IE6.
413> The browsers who do not show ALT tooltips simply have become _irrelevant_.

If that were true, it doesn't matter what we do. Why write for any browser other
than IE6/Win? Why write software for any platform other than Windows? Why make
pages accessible to anyone other than the sighted?

Let's not try to be IE6. There already is an IE6 that will always be better
at being IE6. Mozilla can best be relevant by being a better browser than IE6.
Let's aim higher.


In #412, Dan misunderstands my opinion:
412> (I'm a serious proponent of web standards, but unlike you, I'm
412> not under the illusion that showing ALT tags as tooltips if there's
412> no TITLE attribute is against the language or spirit of those standards).

That's not my position. In #402, I said, "The alternate text is meant to be
rendered in place of the image when it is not, but it is not disallowed to
render both at once." There's nothing illegal about alt tooltips.

To me using alt for the purpose of producing a tooltip is like using
<blockquote> to indent text. It's a mistake to assume users can view
both.

Small screen browsers might render <blockquote> as italicized paragraphs,
a reasonable rendering for a block quotation. Some authors misuse
<blockquote> to mean <indent> since that presentation is common for them.
But it's not the browser's fault if that's not the presentation they get.
<blockquote> was never designed to be <indent>.

Similarly all a standards compliant browser need do is provide alt text
as a replacement when an image is not rendered. Some authors assume that
users will be able to view both the image and its replacement text at
the same time, because it was once a nice feature to pop up alt text.
But it's not the browser's fault if that's not the presentation they get.
alt="" was never designed to be tooltip="".

There are reasons IE/Mac, Netscape, and Opera have all dropped this
presentation of alt text. Good alt text for graphical horizontal rules,
list bullets, labelled buttons, rendered text, and so forth makes for 
lousy tooltips. Conversely, the Flavell article shows how bad tooltip text
can be as text substitutions for images. We have a better attribute for
tooltips in title.  Alt tooltips are obsolete for good reason.

If someone added a preference to make alt text into tooltips in Mozilla,
as long as I don't have to see them, I wouldn't cavil. I don't mind much
if other users choose to subject themselves to more popups. But I think
a preferable feature would be an easy way to toggle all images on and off,
which would be a simple way to view all the alt text on the page at once.
That's a feature I used often in Netscape 4.x, one I still use in Opera,
and one I'd like to use in Mozilla.


Way back in #266, Brian suggested:
266> We could add a some META attribute, or something that allows people
266> to have ALT tags displayed on web pages they add it to. Adding it
266> would make them aware they are breaking the standards. I'm sure this
266> will be shot down, but its just an idea.

Just as an aside, if 'tooltip' makes it into CSS3, one day the formula Brian
seeks might be:

<style> img { tooltip: attr(alt) } </style>

Though as was said in #267, if you could get that added, you may as well just
add title attributes.
Robin Lionheart writes:
> Small screen browsers might render <blockquote> as italicized paragraphs,
> a reasonable rendering for a block quotation. Some authors misuse
> <blockquote> to mean <indent> since that presentation is common for them.
> But it's not the browser's fault if that's not the presentation they get.
> <blockquote> was never designed to be <indent>.

But the two browsers in your <blockquote> example are making a best-effort
attempt to render the content given the display size they're working with.
In the case of pages designed assuming ALT text popups (especially HTML 3.2
pages where there's no TITLE attribute), Mozilla is _not_ making a best
effort to display the information -- instead, it's trying to obfuscate it for
questionable reasons.

> because it was once a nice feature to pop up alt text

If it was once a nice feature, then it still is, especially when browsing pages
written before there was another way to do it.

> Good alt text for graphical horizontal rules, list bullets, labelled buttons, 
> rendered text, and so forth makes for lousy tooltips.

Granted, but by their nature, none of those items are likely to confuse, so I
won't be hovering my mouse pointer over them.  If I hover my mouse over one of
them by accident and get an ALT text tooltip containing rendundant text, I don't
find it onerous to move my mouse, or possibly be checking out other parts of the
page as the tooltip times out.  That's a tradeoff I'm happy to make in order to
get quick access to the ALT text in the usual case, where it _isn't_ just a
plaintext version of graphically-rendered text in an image.

> If someone added a preference to make alt text into tooltips in Mozilla,
> as long as I don't have to see them, I wouldn't cavil.

Cool!  Now if David Baron won't, um, cavil either, we're getting somewhere...

> But I think
> a preferable feature would be an easy way to toggle all images on and off,
> which would be a simple way to view all the alt text on the page at once.
> That's a feature I used often in Netscape 4.x, one I still use in Opera,
> and one I'd like to use in Mozilla.

Yes, I also miss that feature from the Netscape 3.x days.  However, I wouldn't
consider it an acceptable replacement for the ALT text popups.  In the general
case, it's too slow to have to wait for the whole page to re-render to see the
ALT text for a single image you're interested in.  And because the page layout
will necessarily change if you're making image placeholders big enough for their
entire ALT text, one is likely to have the problem of the image whose ALT text
you were looking for being in a very different location after the mode switch,
and having to hunt it down...
426> Granted, but by their nature, none of those items are likely to confuse,
426> so I won't be hovering my mouse pointer over them.

Banner ads and interstitial advertising by their nature are positioned in places
where your pointer will probably pass over their pesky pitches. Popping up
redundant replacement text makes them even more irritating.

Many e-commerce sites have stacks of buttons or rows of tabs labeled with the
various product types they offer. To get to the category you want, you move your
pointer across the list to the one you want. Redundant replacement text popping
up for each item would just get in the way.

What's worse, the practice of popping up replacement text is a discouragement to
shopping sites from including it at all, to the detriment of users of text-only
browsers.
> What's worse, the practice of popping up replacement text is a discouragement 
> to shopping sites from including it at all, to the detriment of users of 
> text-only browsers.

Exactly.

This is _exactly_ why we don't want to show alt attributes when images are
enabled. This has been the argument ever since the issue was first raised in
early 2000.

It's worth noting that NO modern browser apart from Windows IE shows alt
attributes as tooltips. Safari, Opera, Konqueror, Amaya, MacIE: none of them
show any tooltips for alt attributes. So even Microsoft agree with us here.

Also, please, the idea that this issue will have the slightest impact on our
marketshare is laughable. Most users do not have a clue what tooltips are, let
alone that they should or shouldn't appear. And our marketshare is going up, not
down, despite this issue.

If you, as a user, want this, we have given you multiple easy ways of getting
the behaviour you want.
"What's worse, the practice of popping up replacement text is a discouragement
to shopping sites from including it at all, to the detriment of users of
text-only browsers.

Exactly.

This is _exactly_ why we don't want to show alt attributes when images are
enabled. This has been the argument ever since the issue was first raised in
early 2000."

Excuse me. I do not know "only" graphical user interfaces, I started programming
on text-only Wyse terminals connected to Sun OS machines (that was before they
renamed it to Solaris) or microVAXes, and I have worked on 3270s, so I know the
benefits of text interfaces very well. And their restraints.

But I believe _for users_ the time of text interfaces is over. I think after
almost ten years of graphical web content and far more than ten years of GUIs
for practicall all OS it is fair to say that text mode browsing is now
unsupported. I do not know of any commercial web site that officially supports
Lynx. Mozilla's market share is minimal, but Lynx' market share IMHO is nearly
non-existent.

That may seem unfair to Lynx users, and I do not want to offend them, but taking
text-only browsers into consideration involves far more complications than just
ALT and no one will invest money into that. And please do not mix Lynx support
with screen reader support for blind people. Blind people can very well surf
graphical, as long as webmasters follow some basic rules. ALT is one of them.

"Also, please, the idea that this issue will have the slightest impact on our
marketshare is laughable."

Maybe you think of this a laughable. My customers _do_ complain about it. Look
at the number of dupes of this bug and you will see that this is something that
a large number of people view as a bug that needs fixing. But it's not the lack
of this important feature, but the ideological view behind the lack, that makes
people go back to IE. "It runs so well".

"So even Microsoft agree with us here."

No, they don't. Mac IE has been declared dead my Microsoft, it will no longer be
developed on.
> But I believe _for users_ the time of text interfaces is over.

"Text only browsers" includes the increasing number of audio-only speech
browsers, critical to those who are blind or have a serious sight disability,
and also for geeks who like to use the latest gadgets.


> And please do not mix Lynx support 

I didn't say Lynx; you did.


> with screen reader support for blind people. Blind people can very well surf 
> graphical,

Screen readers are a hack compared to native HTML with Speech CSS support.


> as long as webmasters follow some basic rules. ALT is one of them.

Exactly. And alt attributes are more likely to be included if graphical browsers
do not turn around and use them for tooltips.


> My customers _do_ complain about it.

By your customers do you mean people for whom you have installed Mozilla, or
people who use your Web site? If the former, then you should install one of the
extensions that sealessly provides this feature if your customers really do need
it for the sites they use. If the latter, fix your site.


> Look at the number of dupes of this bug and you will see that this is 
> something that a large number of people view as a bug that needs fixing.

Actually most people who file dupes of this bug read the explanation and then
explain that they didn't know about the title attribute and understand and agree
with the current implementation.


>> "So even Microsoft agree with us here."
> No, they don't. Mac IE has been declared dead my Microsoft, it will no longer 
> be developed on.

So has Windows IE, so I'm not sure what that is supposed to prove. The rendering
engine behind MacIE (codenamed Tasman) is still in active development, and it
doesn't show alt attributes for tooltips.
"Text only browsers" includes the increasing number of audio-only speech
browsers, critical to those who are blind or have a serious sight disability,
and also for geeks who like to use the latest gadgets."

No, many audio browsers are graphics browsers. They do display graphics like any
other browser and tell the blind user "graphics" or "body text" when they
mouseover (or use the sliders on their keyboards), or they tell them ALT or
TITLE. The graphics are displayed on the screen for a simple reason: Blind
people in office environments want to be able to ask a seeing person for help.
Therefore, the image is rendered _and_ the ALT text is processed.

"I didn't say Lynx; you did."

Lynx is a text-only browser. Browsers for the blind (at least some of them) are
graphics browsers.

"Screen readers are a hack compared to native HTML with Speech CSS support."

Admitted, yes. But since CSS support is so lousy in so many browsers people rely
on that small amount of technology that really works and has worked for many
years and that people know. Screen readers have the advantage over HTML/CSS
audio enhancements that they work with (almost) every web page more or less if
the webmaster has not made fundamental mistakes.

"Exactly. And alt attributes are more likely to be included if graphical
browsers do not turn around and use them for tooltips."

Why? I dare to say the opposite. Having them as tooltips makes them more popular
because then they make a benefit even for seeing people.

"By your customers do you mean people for whom you have installed Mozilla, or
people who use your Web site? If the former, then you should install one of the
extensions that sealessly provides this feature if your customers really do need
it for the sites they use. If the latter, fix your site."

I mean people who pay me for the service that I run their corporate,
organizational or private network. For the former: That's what I did. But many
of my customers are not computer-illiterate. They sometimes update themselves,
breaking the extensions. For the latter: A site using ALT is not broken, as so
many people pointed out. And no, I will not edit all the 700 static web pages
written in HTML 3.2 I have written in the past.

"Actually most people who file dupes of this bug read the explanation and then
explain that they didn't know about the title attribute and understand and agree
with the current implementation."

Is that so? Did you talk to them? Since the TITLE discussion is easy to find in
Bugzilla, why to those people have to be manually introduced to the TITLE
discussion? To me it seems that these people, at least when they file the bug,
are not satisfied with the contects of the discussion.

"So has Windows IE, so I'm not sure what that is supposed to prove."

No, Windows IE is _not_ dead. Mac IE is. Windows IE is not going to be a
separate product anymore (which will make transition to Mozilla even harder).
Mac IE will no longer be developed on. Microsoft says openly that Safari
(therefore Konqueror) has more features and is easier to adapt to Mac OS.

"The rendering engine behind Mac IE (codenamed Tasman) is still in active
development, and it doesn't show alt attributes for tooltips."

Since Mac IE and Windows IE have nothing in common, that doesn't change
anything. I don't care about Microsoft's internal playgrounds.
Oliver: I use Lynx when I install Linux and need to get the Nvidia drivers to be
able to run X. Also, Lynx is much faster for certain things. Some people I know
only use Lynx. Some people disable images. I don't think text-based browsing is
gone, just not as popular. Do you really want to lose those few customers that
won't buy something from your site because you don't support Lynx or browsing
with images disabled? :-)
> And no, I will not edit all the 700 static web pages
> written in HTML 3.2 I have written in the past.

All you are doing is editing the ALT and TITLE text. I doubt 700 pages would
really take that long.
"All you are doing is editing the ALT and TITLE text. I doubt 700 pages would
really take that long."

Manually editing 700 pages takes about three man-days, which I am not willing to
spend just to please some ideologists, while the existing pages runs perfectly
for more than 90% of all users.

"I use Lynx when I install Linux and need to get the Nvidia drivers to be
able to run X."

First, I never questioned that there are _some_ people using Lynx, and that's
okay. Otherwise, it would not be further developed, which it is. Second, you do
not need a text-mode browser to download Nvidia drivers, because you don't need
them to start X. Just use your trusty standard VGA driver 640 x 480, 4 bit...

"I don't think text-based browsing is gone, just not as popular."

Not as popular. That's the point. It's question of definition of threshold when
something deserves to be called "gone". Does the relation Lynx to IE users equal
one to the fifth power of ten? I prefer to call that "gone".

"Do you really want to lose those few customers that won't buy something from
your site because you don't support Lynx or browsing with images disabled?"

Yes, I definitely want to lose that customers, and I am dead serious about this.
Why do I want to lose those customers? Because I do not make money with them, I
lose money instead. Because the add'l workload their special needs would make
far outweigh any potential turnaround they could make.
>> So even Microsoft agree with us here.
> No, they don't.

Actually, yes, they do. Tantek Celik, a respected Microsoft employee responsible
for the development of one of their rendering engines and also Microsoft's W3C
representative, recently posted to www-html saying that alt attributes shouldn't
be shown as tooltips:

   http://lists.w3.org/Archives/Public/www-html/2003Jun/0109.html
I've read several articles talking about how the Macintosh apps unit of
Microsoft in recent years has operated in a very independent manner and with
some very different philosophies than the rest of the company (as indeed would
have to be the case in order to aim for superior software for the competing OS
platform).

So it's much too strong of a statement to say that "Microsoft agrees with us"
based on the strength of the Mac version of IE behaving a certain way.  Not
until IE for Windows (the dominant browser on the planet) stops displaying ALT
text as tooltips will you be able to say that.
I don't really feel Microsoft will be around in a couple years, so make sure we
revisit the "Most popular browser on the web" statement then. :-)
http://newsforge.com/newsforge/03/06/16/1552233.shtml

[Switch to Mozilla browser and mail] and other replies.
(Exact title is "Friends don't let friends use Outlook Express")
This shows up what people[AVERAGE USERS] think about mozilla. (And its
competitor, IE.)

Last but not least, why you so strict to standard? Standard is for what?
I just found an example of a large company that stopped putting replacement text
on images because of alt tooltips:

"However, now that Lynx represents 0% of the traffic to our site, and since ALT
text is now used as tooltips on other browsers, we can no longer guarantee that
ALT text will be in place for images. You will have to customize a separate
application such as Tin to access Borland newsgroups."
-- http://info.borland.com/sitetools/helpfulhints.html

"I just found an example of a large company that stopped putting replacement
text on images because of alt tooltips:"

Did you recognize that the page you quote is extremely old? It talks about Opera
3.2 and Netscape 4.05... And it lists dozens of browsers, even Mosaic and Amaya.
But not one single word about Mozilla (probably because Mozilla didn't even
exist when this page was drafted)...

"However, now that Lynx represents 0% of the traffic to our site, and since ALT
text is now used as tooltips on other browsers, we can no longer guarantee that
ALT text will be in place for images. You will have to customize a separate
application such as Tin to access Borland newsgroup."

This is of course nonsense, all browsers that I know of do display ALT if images
are not rendered. Tooltips do not harm image replacement in _any_ way.

IMHO this message is just a polite version of "we don't do Lynx because nobody
uses it anymore, so do not ask for Lynx support".
>> However, now that Lynx represents 0% of the traffic to our site, and since ALT
>> text is now used as tooltips on other browsers, we can no longer guarantee 
>> that ALT text will be in place for images. You will have to customize a 
>> separate application such as Tin to access Borland newsgroup.
>
> This is of course nonsense, all browsers that I know of do display ALT if 
> images are not rendered. Tooltips do not harm image replacement in _any_ way.

I think you misunderstood that author's point. They didn't want to have alt
attributes, because doing so would cause tooltips to appear.


> So it's much too strong of a statement to say that "Microsoft agrees with us"
> based on the strength of the Mac version of IE behaving a certain way.

I didn't base it on that. I based it on Microsoft's W3C representative stating
that he agreed that showing alt attributes is wrong.
I could have trimmed that quote better. I'll add a little more context so the
meaning is clearer:

"If You Are Using Lynx:

Recent versions of Lynx can handle tables enough to display Borland's Web site
coherently. However, now that Lynx represents 0% of the traffic to our site, and
since ALT text is now used as tooltips on other browsers, we can no longer
guarantee that ALT text will be in place for images."

In other words, Borland is saying, "Lynx users, if our images don't have alt
text it's because we don't get Lynx traffic and other browsers use it for tooltips."

Perhaps the irony of telling Lynx users that nobody comes here with Lynx was
lost on the writer.
"I think you misunderstood that author's point. They didn't want to have alt
attributes, because doing so would cause tooltips to appear."

As I wrote, I think they just wanted to tell Lynx users not to beg for support
anymore. It's obviously a five year old paper! There is no reason why tooltips
would present any harm for image replacement.

Also, they did not state they would not do ALT anymore, they only wrote they
would not _guarantee_ their existence. If you look at the source code of
Borland's home page, you will quickly see that they continue to use ALT.

"I didn't base it on that. I based it on Microsoft's W3C representative stating
that he agreed that showing alt attributes is wrong."

Pardon me, IMHO the article you quoted was not written by Microsofts W3C
representative. Tantek Celik may be the Microsofts rep, and he certainly is a MS
employee, but the article in question was written with an e-mail account from
the University of Stanford.

It is news to me that official Microsoft statements issued by Microsoft
representatives appear on Stanford letterhead. And I don't think it's by mistake
the wrong sender's address, because the article is signed just with the (first)
name. That would also be unusual for official Microsoft statements. There is no
mention of the position within _any_ company.

IMHO this looks like the personal opinion of Tantek Celik. I may be mistaken,
but to find out whether it is personal or official Microsoft politics is so
easy: just look at Microsoft's browser. Currently Microsoft's one and only
browser dooes show ALT tooltips, the other one that did not was just discontinued.
If alt text is used for tooltips, an image's alt text can override the title of
a enclosing link tag.

Take the case of a validator button:

<a href="http://www.htmlhelp.com/cgi-bin/validate.cgi?url=referer"
title="Validate this page"><img src="/buttons/html4.gif" alt="Valid HTML 4.0"></a>

In Internet Explorer 4.0, the "Valid HTML 4.0" alt tooltip will override the
link tooltip of "Validate this page", overriding useful information about a link
with redundant information about an image.
> Pardon me, IMHO the article you quoted was not written by Microsofts W3C
> representative. Tantek Celik may be the Microsofts rep, and he certainly is a 
> MS employee, but the article in question was written with an e-mail account 
> from the University of Stanford.

Actually, all of Tantek's W3C e-mails are from that address, including his
official ones. (If you are a W3C member you can verify this by looking at the
CSS WG mailing list archives.)


> It is news to me that official Microsoft statements issued by Microsoft [...]

I'm not saying this is Microsoft's official position. I doubt Microsoft give the
slightest care in the world about alt attributes. This issue is pretty minor to
most people. I was merely saying that their rep stated his agreement. Since this
is Microsoft's HTML WG representative, his opinion is the one that matters as
far as Microsoft goes with respect to HTML.


> Currently Microsoft's one and only browser dooes show ALT tooltips, the other 
> one that did not was just discontinued.

Microsoft have way more than just one browser, and Tasman is used in at least
one if not two products currently in active development (MSN Explorer for Mac
being the main one that comes to mind).

The latest browser product to come out of Redmond (actually, the MSN explorer
team is based in Microsoft's Mountain View campus) is based on Tasman, is still
in active development, and does not show tooltips for alt attributes.

Ditto for the latest product out of Apple, and the latest product out of Opera.
> Also, they did not state they would not do ALT anymore, they only wrote
> they would not _guarantee_ their existence.

They wrote they would "no longer" guarantee their existence, implying their
policy before was to always use alt text.

> If you look at the source code of Borland's home page,
> you will quickly see that they continue to use ALT.

They still have it on that page. No guarantees on the others, but let's hope
they've reconsidered.

Whether or not they've reversed this position, this is a documented case of alt
tooltips discouraging a company from putting alt text on their pages.
434> Manually editing 700 pages takes about three man-days, which I am not
434> willing to spend just to please some ideologists, while the existing
434> pages runs perfectly for more than 90% of all users.

I knocked off a perl script to do it in 15 minutes. Here you go, Oliver:

-->8 snip

#!perl
while (<*.html>) {
	$filename = $_;

	s/html$/out/;
	$newfilename = $_;

	print "$filename -> $newfilename\n";

	unless (open INPUT, $filename) {
		print STDERR "Can't open input $filename: $!\n";
		return;
	}
	unless (open OUTPUT, ">$newfilename") {
		print STDERR "Can't open output $newfilename: $!\n";
		return;
	}

	while (<INPUT>) {
		# update doctype HTML 3.2 -> 4.0 Transitional
		s/<!DOCTYPE HTML PUBLIC "-\/\/W3C\/\/DTD HTML 3.2\/\/EN">/<!DOCTYPE HTML
PUBLIC "-\/\/W3C\/\/DTD HTML 4.01 Transitional\/\/EN"
"http:\/\/www.w3.org\/TR\/html4\/loose.dtd">/i;

		# copy alt to title
		s/alt="([^">]+)"([^>]*)>/alt="\1" title="\1"\2>/gi;

		# write line to output
		print OUTPUT $_;
	}

	close $input;
	close $output;
}

-->8 snip

Run this script in each directory that has HTML files you want to convert, then
copy the *.out files over the *.html files.
Er, those last two lines should have read
 
close INPUT;
close OUTPUT;

The script worked when I tested it regardless.
Robin Lionheart writes:
> If alt text is used for tooltips, an image's alt text can override the title of
> a enclosing link tag.

Okay, that's perhaps the first legitimate case I've seen of harm caused by ALT
tooltips.  However, just because IE and the Popup ALT Attributes XUL (which I
couldn't get to work on Linux installing for just my account, BTW -- had to
install it for everyone as root) do it that way doesn't mean an implementation
within Mozilla would have to have that behavior.  A TITLE attribute from an
enclosing tag could override.
"I knocked off a perl script to do it in 15 minutes."

First, let me thank you for your work.

But I'll have to add some comments. It's just not as easy as you think it is.
With changes, adaptations, test runs and debugs it still takes too long.

- The content is dispersed over 281 subdirectories
- The source HTML files mostly do not have a 3.2 declarator
- The HTML 4.0 files do not have standard DTD declarator as I need frames with 0
pixel distance, that requires a non-standard DTD
- The target files cannot be "just" 4.01 transitional, they have to be 4.01
frameset and loose, depending on their function and content
- The target files have to have non-standard DTDs as well
- I used upper case and lower case tags to differentiate between manually and
automatically coded lines
- It has to be tested whether or not the program could under extreme
circumstances interfere with the content, requiring checks
- Several images in so far unknown locations already have TITLE
- Your script produces identical ALT and TITLE, which has been declared evil by
some participants here
- Having identical ALT and TITLE produces problems on some browsers
- Not having ALT would disable tooltips on Netscape 4

And afterall, most of my content is out of reach. Anything done for projects
that are finished is off limits.

You see, it's a whole range of problems that only arises for a very small
minority of surfers that could simply be avoided if Mozilla had a pref that
would turn on ALT tooltips if the users so wishes. It doesn't hurt anybody,
except perhaps the most orthodox...

And I consider my sites _very_ small to the sites that some people I know have
built... Talking about hundreds of thousands of pages...

But again, thanks.
*** Bug 211513 has been marked as a duplicate of this bug. ***
*** Bug 67093 has been marked as a duplicate of this bug. ***
*** Bug 66282 has been marked as a duplicate of this bug. ***
*** Bug 88297 has been marked as a duplicate of this bug. ***
*** Bug 211513 has been marked as a duplicate of this bug. ***
There is some scope for making life easier for those who want ALT tooltip
support, with a small change to Moz / Firebird. In embedding there is a
nsIToolTipTextProvider interface which can be implemented by clients as a
service that want to supply different tooltip text for a node. When the user
hovers over the node, the provider service is asked (if it exists) to provide
the text for the supplied DOM node. The default provider just looks at the TITLE
attribute, but it could be overridden by one that looks at ALT text or anything
else.

Note this is only in embedding at the moment which has its own DOM mouse
listeners to generate tooltip events). This service is so simple it would even
be possible to write it in Javascript.

It would be beneficial if the Mozilla chrome also looked for this service before
displaying the tooltip. Then for anyone who wants ALT tags, it is a simple
matter of creating and copying a ToolTipProvider.js service into components/ and
it would would be called to supply the text.

I doubt such support is ever going to appear by default but it would be
straightforward enough to write an extension .xpi package that enabled it for
people who install Mozilla or Firebird.
If you _just_ want alt tag poped, use this extansion.
It works well as moz as fb.
http://www.texturizer.net/firebird/extensions.html#Popup%20ALT%20Attributes

If js alert appeared, go to author's site.
http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en?SSSStyle=Limited#download
One aspect that I haven't seen mentioned in this discussion is the predominate
use of ALT tags currently exclusively for Tooltip behaviour.

By this I mean, most uneducated web authors (that is to say *most* web authors,
by a very large margin), use ALT tags for Tooltips without even realizing that
can (and is designed to be) used as an Accessibility aid. Given that, once it
becomes universal that TITLE alone produces tooltips, most authors will no
longer write ALT tags, period. This seems contrary to goal stated by the "no ALT
popup" advocated who fear blind users being mislead by inappropriate ALT tags.
Authors who wish to accomodate Accessible browsing will do so, properly, whether
or not ALT tags so tool tips or not. Leaving us with two scenarios for the bulk
of web pages:

ALT tags produce tooltips: Blind users get *some* feedback as to the meaning of
images, by virtue of ALT tags placed there for a wholly seperate reason (tooltips)

ALT tags do not produce tooltips: Blind users get *no* feedback for images, as
most authors abandon ALT in favor of TITLE.

Despite the fact that they don't realize it, web authors today are providing
accessibility to users through the use of ALT, which to them is just a method of
creating tooltips. Remove it, and most authors will simply not use ALT leaving
blind users without any feedback; all in the name of preventing them from
receiving inappropriate feedback. It seems to me that it is better to provide
ALT tooltips; making Websites more accessible (if only by accident).
XHTML requires alt="" to be valid code.
So it probably should be utilized as in all other browsers.
Below from: http://www.useit.com/

Disabled Users and the Web (Alertbox) 12/07/03

All imagemaps should be client-side and should use ALT attributes for each of 
the link options so that a user who cannot see the image can have descriptions 
of the destination read as he or she moves the cursor around. There are still 
some browsers that only support server-side imagemaps, but client-side imagemaps 
are clearly the way to go in the future.
Sighted users would also benefit from having ALT attributes displayed in the 
appropriateparts of the picture rectangle if they didn't want to wait for the 
image file to download, and it is rather obvious that an ALT attribute can 
describe the meaning of the hyperlinkdestination in much more user-friendly
terms than a weird URL. In general, it is often the case that design rules that 
may have been intended to help users with disabilities end up
being of benefit to all users. 
Per: http://www.w3.org/TR/WAI-WEBCONTENT/

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", 
"longdesc", or in element content). This includes: images, graphical 
representations of text (including symbols), image map regions, animations 
(e.g., animated GIFs), applets and programmatic objects, ascii art, frames,
scripts, images used as list bullets, spacers, graphical buttons, sounds (played 
with or without user interaction), stand-alone audio files, audio tracks of 
video, and video. [Priority 1] 
 For example, in HTML:  Use "alt" for the IMG, INPUT, and APPLET elements, or 
provide a text equivalent in the content of the OBJECT and APPLET elements. 
For complex content (e.g., a chart) where the "alt" text does not provide a 
complete text equivalent, provide an additional description using, for example, 
"longdesc" with IMG or FRAME, a link inside an OBJECT element, or a description 
link.  For image maps, either use the "alt" attribute with AREA, or use the MAP 
element with A elements (and other text) as content. 

So: Mozilla should display the result of alt=""
http://www.w3schools.com/tags/tag_img.asp  (XHTML)

Required Attributes
DTD indicates in which DTD the attribute is allowed.
 S=Strict,T=Transitional, and F=Frameset.

Attribute  Value  Description                                     DTD
alt        text   Defines a short description of the image        STF
src        URL    The URL of the image to display                 STF

Again: Mozilla should use this content as intended.
Word is that Windows IE will be rewritten to use Tasman, and therefore since its
most of the browser market, this bug will be moot if that happens.
*** Bug 218626 has been marked as a duplicate of this bug. ***
*** Bug 221022 has been marked as a duplicate of this bug. ***
*** Bug 221266 has been marked as a duplicate of this bug. ***
Bug 221320 offers a commentary on why the Element Properties workaround
suggested in http://bugzilla.mozilla.org/attachment.cgi?id=124200&action=view is
inadequate. (By extension the Page Info workaround is also inadequate.)  While I
do not agree with the decision to mark this bug as WONTFIX, I won't argue that
point. What I will say is that given that decision, some easy method of
accessing the alt text SHOULD be provided by Mozilla without requiring a plug-in
to fix the problem.  Long alt texts are not easily accessable at present.
I really think this WONTFIX is overzealous recalcitrance, and self-righteous
stubbornness.  There are millions of webpages with icons and other flair where
the alt and title (tooltip) text are quite appropriately identical.  It's
foolish to overlook the efficiency of tooltippifying alt text when there isn't a
need for a separate title.  Nothing you do with the development of this web
browser will stop people from thinking "Well none of my users/clients are blind"
or "all of my friends have broadband" etc.  This is a reality that exists far
more pervasively than in our tiny world of bits and bytes, and you're not helping.

IE's behavior is accessibility friendly - it doesn't stop anyone from writing an
accessible web page.  As stated numerous times, the published standard doesn't
explicitly deprecate tooltipping alt text, either.

The WONTFIX status is causing more damage to mozilla than it will ever cause
help to people who cannot access images.

The stated commitment to ignoring all further complaints on this lack of
function is really immature, too.
*** Bug 221986 has been marked as a duplicate of this bug. ***
> It's foolish to overlook the efficiency of tooltippifying alt text
> when there isn't a need for a separate title.

It's inefficient to require <img src="hr.gif" alt="---------" title=""> 
when a tooltip is undesirable.

> Nothing you do with the development of this web browser will stop 
> people from thinking "Well none of my users/clients are blind"
> or "all of my friends have broadband" etc.

> IE's behavior is accessibility friendly - it doesn't stop anyone from
> writing an accessible web page.

It stopped Borland. That "none of our users our blind" thought seems to
have combined with a "tooltips are messing up our pages" thought, leading
them to decide to stop using alt text. See #442.
Reply to Comment #470, Robin Lionheart:
>It stopped Borland. That "none of our users our blind" thought seems to
>have combined with a "tooltips are messing up our pages" thought, leading
>them to decide to stop using alt text.

No, it seems you are wrong, not stopped Borland. Borland said:
"we can no longer *guarantee* that ALT text will be in place for images".
They really don't guarantee to have ALT everywhere.
But they still use ALT text where appropiate:
http://www.borland.com/cbuilder/index.html
<img alt="DEVELOP : DEPLOY : INTEGRATE" border="0" height="80" width="277"
src="/images/products/dev_dep_int_ani.gif">
or
<img alt="Register" border="0" width="135" src="/images/nav/btn_register.gif">


And not stopped several other big companies from the TOP WEB PAGES, which are
still using only ALT, but not TITLE:
http://www.mozilla.org/quality/browser/front-end/testcases/printing/websites.html

Especially those big ones listed here:
- www.Netscape.com
- www.yahoo.com
- www.CNN.com
- www.microsoft.com
- www.cnet.com
- www.sony.com
- www.sonypictures.com
- www.ebay.com
- etc... etc... etc...

Aren't these big enough? 
Look at that small list I collected in minutes from your Mozilla testcase TOP
list. And the are a lot more sites...
It's funny that you Mozilla developers, think that will change the world by
forcing something :)
Unfortantely, if all those millions of users who visit these top sites, would
use Mozilla, they would use the sites difficulter because of lack of tooltips.
You may not imagine that beginner users using websites & windows software, how
much are relying on these small tooltips, which helps understanding what button
is doing what. And that's only the user side.

BY THE WAY: the developer's job is to *SERVE* the world, not to force it to change!

Did you also see www.aol.com? 
They duplicated each and every ALT & TITLE text. They have ALT="my long text"
TITLE="my long text" exactly duplicated everywhere, resulting to increase the
internet traffic, unnecessarily :-(
This is a result of what you Mozilla developers force. One big company, AOL,
implemented your idea (note: Mozilla project is also maintained by employees of
Netscape, now a division of AOL). But AOL developers will have never time to
differentiate ALT and TITLE texts, so they duplicate them (additionally mostly
the ALT & TITLE text could be safely the same, so that is unnecessary).
Don't you see this duplication is against everything for what we developers are
working? We do code reusage as much is possible, and not code duplication. 
Now you force duplication of all informational texts on html pages. That may be
the result of your behaviour.
That's the developer side, which also affects millions of websites (note: I
found 8 of 52 which are not using TITLE attribute, and I did not test all.
That's *at least* 15% of the Top sites, which really means millions of affected
websites).


If you would implement the suggestion to display ALT text as Tooltip, when TITLE
is missing (was suggested several times, and stated that none of the standards
say, that it is not allowed to do), then this kind of text duplication would be
not required. Additionally you could even implement an option, so those who are
disturbed by this feature could turn it off easily.

I would like to use Mozilla with pleasure, with the following in mind: that it
is an open development software which was created by hundreds of people who
wanted to make the world better (and not forced the world same way as Microsoft
did/does). I wish Mozilla behaviour to be different than Microsoft.

Sincerely,
Webmaster33
although i agree with most of what you say AOL no longer funds mozilla through
netscape, they effectively cut it loose with a bit of spare moolah, which will
probably makes things worse because the group of self righteous hippies that now
run the mozilla project don't even have the incling of a commercial product as
their goal.
> And not stopped several other big companies from the TOP WEB PAGES,
> which are still using only ALT, but not TITLE... 

Good. All major websites should make their sites more accessible with
appropriate alt text.

> Especially those big ones listed here:

> - www.Netscape.com
> - www.yahoo.com
> - www.CNN.com
> - www.microsoft.com
> - www.cnet.com
> - www.sony.com
> - www.sonypictures.com
> - www.ebay.com
> - etc... etc... etc...

Let's take a look at the front pages of these sites in Internet Explorer,
and try to find an image where the alt text is a useful tooltip:

> - www.Netscape.com

In IE, hovering over the graphical "Mail", "Radio", and "My Netscape" buttons
pops up their alt text of "Mail", "Radio", and "My Netscape"-- redundant and
useless.

> - www.yahoo.com

Hovering the mouse over the big Yahoo logo pops-up its alt text "Yahoo!", and
hovering over the graphical "Find a domain:" field label pops up its alt text
"Find a domain". Redundant and useless. 

> - www.CNN.com

Today there's a picture of Kobe Bryant next to the headline "'Smear' tactics
alleged". In IE, hovering over the picture produces the tooltip "'Smear' tactics
alleged".

Lower down are smaller article callouts, like a picture of a numbered jersey
with the name BUSH and number 1 next to the article link for "'First
fund-raiser' to the nation". Hovering over the picture pops up the alt text
"'First fund-raiser' to the nation".

The pattern seems to be that all the photos have the article headline as alt
text. No alt text would be better for most of these, rather than have speech
browsers say "First fund-raiser to the nation first fund-raiser to the nation".

> - www.microsoft.com

Microsoft produces the only major browser that still renders alt text as
tooltips, yet even on their home page, all the alt text pop ups are redundant.

The "3 steps to help ensure your PC is protected" graphic pops up "3 steps to
help ensure your PC is protected". 

The face next to the "home & entertainment" bullet list pops up the alt text
"home & entertainment". The face next to the "technical resources" bullet list
pops up the alt text "technical resources". The skyscraper next to "business
agility" bullet list pops up the alt text "business agility". These three are
rendundant both as tooltips and as alt text; these should have null alt text.

Lower down, an image of the words Microsoft Windows next to its logo pops up the
alt text "Windows", an image of the words Microsoft Office next to its logo pops
up the alt text "Office", &c. Need I go on?

> - www.cnet.com

The c|net logo and CNET.com title banner pop up the alt text "CNET.com".

The 'GO DIRECTLY TO CNET'S NEW REVIEWS:' graphic pops up the alt text "Go
directly to CNET's new reviews:". The "> CNET'S TOP 100 PRODUCTS" graphics 
pops up the alt text "CNET's top 100 products".

The computer icon over the word DESKTOPS pops up the alt text "Desktops". The
notebook icon over the word NOTEBOOKS pops up the alt text "Notebooks". And so on.

The graphic headline ">>> DELL ENTERS THE holiday handheld race" pops up the 
alt text "Dell enters the holiday handheld race". And so on.

- www.sony.com

The SONY logo pops up the alt text "Sony". The SEARCH: label next to the input
box pops up the alt text "Search Sony:". The GO button on the other side of the
input box pops up the alt text "GO". The "> Global Home" button pops up the alt
text "> Global Home".

The large "music, movies, tv, games, electronics // welcome to the world of
Sony" graphics pops up the alt text "welcome". "what's new" pops up the alt text
"Whats New". The welcome and what's new graphics also has some image map links
which are not duplicated in plain text:

Hovering over the the woman with the camera (an unobvious link to their digital
camera section) pops up the <area>'s alt text "Put the power of Sony digital
photography in the palm of your hand." This one ought to have a title attribute
as well as an alt.

In the what's new graphic are some imagemap 'headlines' like "> Customize your
own VAIO(r) RZ Series Desktop" which pops up the <area>'s alt text "VAIO(r) RZ
Series Desktop". 

Further on, the SEE tab pops up the alt text "SEE". The HEAR tab pops up the alt
text "HEAR". The PLAY tab pops up the alt text "PLAY". The SHOP tab, &c. 

> - www.sonypictures.com

Sony Pictures' site needs more alt text.

The SONY PICTURES banner has no alt text. The button next to the text box has
no alt text, so lynx users will only have to assume it's a search box. 

Of the images that do have alt text:

Image of movie still next to RADIO text link pops up alt text "RADIO". Image of
Home Room DVD next to HOME ROOM text link pops up alt text "HOME ROOM". Image of
Qbert on a cell phone next to QBERT MOBILE text link pops up the alt text "QBERT
MOBILE". So far so useless.

And so for the "Movies", "Television", &c. headings, the still over the links to
IN THE CUT, THE MISSING, IDENTITY all poping the same words just below them, &c. &c.

> - www.ebay.com

The eBay(r) logo pops up the bad alt text "eBay Logo". Some Web designer at eBay
just doesn't get it.

The "Browse" button pops up the alt text "Browse", &c.

> - etc... etc... etc...

In my opinion, my cursory review has validated my opinion that efficiency would
be better served by webmasters duplicating alt and title attributes in the few
instances where the text is actually useful as a tooltip, than by webmasters
adding title="" attributes to suppress tooltips in the far more common case
where they are useless and obtrusive.
I think it's not your job to criticize the TOP websites & their developers,
about how they code their sites, and how they use available features. They made
their sites IE compatible which covers the 95% of the visitors.

>efficiency would be better served by webmasters duplicating alt and title 
>attributes in the few instances where the text is actually useful as a tooltip,
>than by webmasters adding title="" attributes to suppress tooltips 

I absolutely don't aggree with you, that would be efficient to duplicate ALT &
TITLE attributes. 

Trust me, duplicating would be more time required, than adding title=""
attributes, because a webmaster doesn't want any tooltip to display. Duplication
would be not efficient in any way...
Most webmasters would not want to suppress displaying tooltips, because they
like tooltips, and they don't think it is disadvantage, especially not the
visitors who like the tooltips, as they can get quick info about website usage &
content.
471> Did you also see www.aol.com? 
471> They duplicated each and every ALT & TITLE text. They have ALT="my long
471> text" TITLE="my long text" exactly duplicated everywhere, resulting to
471> increase the internet traffic, unnecessarily :-(

That's not what I see at the http://www.aol.com/ front page. There I see a login
form where the labels of the text boxes have no alt text at all. In a text
browser it's just two unlabeled input fields.

Doing a search from their search box, I don't see duplicated alt and title in
the results either. The search botton has bad alt text and no title:

   <input type="image" src="/gr/SearchButton.gif" alt="search button.  click to
search." class="butImg"/>

Each search result has a little new-window icon with bad alt text and a passable
link title:

   <a href="redir?..." target="_blank" title="Open this website in a new
window"><img src="/gr/pw.gif" width="12" height="12" border="0" alt="icon"/></a>

Note that if the bad alt text were tooltipped in Mozilla, then hovering over
it would pop up the bad alt text "icon" instead of the useful link title of
"Open this website in a new window". (See comment #444 for a better example 
of this problem.)

I don't have an AOL account, so I can't speak for the pages that show up once
you log in. From what I've seen of the public pages, however, I suspect your
assertion that they duplicate title and alt attributes throughout is exaggerated.

474> I think it's not your job to criticize the TOP websites & their 
474> developers, about how they code their sites, and how they use available
474> features.

Well, as someone who designs websites professionally, criticizing existing sites
_is_ part of my job. But don't let it distract you from my point, that the alt
text on the websites you mention make lousy tooltips which hardly ever provide
"info about website usage & content" that isn't already there.

You make it sound like webmasters must painstakingly retype alt text as title
text for every image. But for most images, you won't be using title at all. 

You don't have to type 'title="Search"' on a button that says "Search" on it.
You don't have to type 'title="Company Name"' to repeat what the page banner
says. You don't have to put 'title="*"' on every graphical list bullet. Those
belong in alt text alone.

If, as a designer, you want anything that's not IE/Win to produce a tooltip,
you'll have to use the title attribute. Most Web browsers-- Mozilla, Netscape,
Opera, Konqueror, Safari, iCab, even Internet Explorer for the Mac-- don't
tooltip alt text.

If, as a user, you really want that alt tooltips, you can get a plugin to
emulate what is now just an IE/Win quirk. See comment #133 or visit
   http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en
>That's not what I see at the http://www.aol.com/ front page

Then you have selective sight :)
Just wrap the source code and check it for title attributes.
Below the login form there are a bunch of buttons. All have duplicated alt & title.
Example:
<img title="AOL Parental Controls" vspace="3" border="0" alt="AOL Parental
Controls" height="19" width="109" src="/PromoArt/parntbt.gif.599.1.gif">

>Doing a search from their search box, I don't see duplicated alt and title in
>the results either.

Hehe, because the search results are from Google :)
But check the design items, image buttons at the top of search page:
<img border="0" alt="AOL Mail on the Web" title="AOL Mail on the Web"
height="44" width="48" src="http://cdn.aol.com/gr/mail_but.gif">
Ok, there are some rare exceptions, like Search button, it only has ALT attrib.

Duplicated alt & title can be also found on AOL corporate website, however
rarely, since it's mostly text based:
http://www.aoltw.com/corporate_information/index.adp

But for example on http://advisor.aol.com/ only ALT attribs are used. No title.
So there is another example from a TOP website, where TITLE attribute is
avoided, and only ALT is used, just because IE will display them correctly as
tooltips, too.

>Well, as someone who designs websites professionally, criticizing existing 
>sites _is_ part of my job. 

Well, you can criticize if you want. But that doesn't really matter.
I listed those TOP sites, because I wanted to show, that EVEN TOP sites still
use only ALT, without using TITLE attrib. And based on the percent I roughly
computed, we can say millions of websites would be affected, if all users would
use Mozilla (it's another thing that Mozilla doesn't have such a lot share of
the market).
But I suppose Mozilla developers want to have Mozilla popular & favoured web
browser in long-term, and in the future that ALT problem may be really
disturbing (and it might however stop some users to migrate to Mozilla, so
that's a power which is somewhat against becoming popular).

>Mozilla, Netscape, Opera, Konqueror, Safari, iCab don't tooltip alt text.

1) Be precise and say "some versions of above browsers"!!! Netscape 4.x, earlier
Opera displayed tooltiped alt text.
2) These browsers even in in overall doesn't take more than 5-10% of market
share (however Mozilla popularity seems to be growing). Most companies doesn't
care to support them, as the TOP site examples shows. But top sites are just
examples, the truth is much worser, since based on this millions of websites may
be affected by the ALT tooltip problem (if Mozilla would the market leader).

>just an IE/Win quirk
96% of my visitors use some version of Windows. So saying "just a Win quirk" is
funny from you :) Did you see the film, Monty Python's: Holy Grail? Mozilla
behaves similar to the knight, who did have no arms, no legs, but still said
"Come on let's fight" :)
Well, it's not really like this, because Mozilla is something that is improving
and slowly takes more and more from the market share, and I also respect Mozilla
developer's time & good work. But your behaviour remembered me that scene from
"Holy Grail".
Unfortunately as desktop system, Windows is the most popular. Linux is not good
desktop system, yet, nor Mac, because of lack of software (note: only compared
to the software amount available on Windows). 

>You make it sound like webmasters must painstakingly retype alt text as title
>text for every image. But for most images, you won't be using title at all. 

It clearly depends on the design. Mostly the tooltip is required on buttons,
menu items, info images, news pictures, family images, galeries, albums, just to
mention a few. On a page with a lot graphic design the design element images not
require tooltips at all (but those usually neither require ALT text).
Also inserting a title="" is easy, but duplicating a text consumes bandwidth,
which may mean several percents, in both page download size & display speed, and
monthly download size.
In overall displaying alt text as tooltip would result less problems, compared
to the situation that you need to dupe texts on website, not to mention those
sites which will never change from ALT to TITLE.

>If, as a user, you really want that alt tooltips, you can get a plugin (popupalt)

I said already, that it is not a solution. A beginner user doesn't even know
that popupalt plugin exists. They mostly install & use a software, some of them
may explore & dig in Preferences to change some options, if they are disturbed
by some features. But that's the maximum an average user does.
That's why I suggested to have ALT tooltip as option, so user can turn off if
doesn't like the feature.
I told you, most users like to have tooltips and would not turn it off.
Mozilla developers's job should be to accept the public demand (it is visible
that there is demand), and implement that asked feature.
Oh, I just found a funny ALT related thing on AOL site:
http://search.aol.com/aolcom/link_to_us.jsp
They suggest to use:
<A HREF="http://search.aol.com/" ALT="Search the web with AOL Search!">AOL
Search!</A>
:-))) The revolution of ALT attrib :-)))
Its not the refusal to fix this bug that bothers me, because I don't think it 
should be fixed. But its the refusal to compramise and give a pref in the 
options I just don't get.
Making the corresponding option available in Preferences is the least of what
should have been done long time ago. Yet I doubt that any number of valid
arguments "pro" are going to convince the few purists running the show. I am
just a user who occasionally donates a few bucks. And yes, personally I do have
the workaround installed. Nevertheless, this patronizing attitude towards the
interests of average users renders me quite uncomfortable. The long awaited
feature is not being implemented merely because someone wishes to entertain
himself with the strictest of all possible interpretations of the standard.
Trying to seem "sainter than Pope", as Russian proverb says, while in fact a
technically minor issue remains unresolved for years.
May be than add one BIG checkbox - "Violate all thinkable standards like IE
does" - and undoubtedly make it checked by default?

> I told you, most users like to have tooltips and would not turn it off.
Mozilla developers's job should be to accept the public demand (it is visible
that there is demand), and implement that asked feature.

If you will do everything that users like you will end up with another IE clone.
Most users like and there is a public demand to drive a car being slightly
drunken, so why not repeal the law?

In fact it's just the question on one or two years - most of the web developers
now start to appreciate standards, most of the developers start to use Mozilla
at least as one of the browsers thay have to consider when creating a site, most
of them DO know, that 'title' is correct attribute of showing tooltips. So
sooner or later but all sites will comply with latest web standatds. Just be
patient.
Reply to Comment #480 From Andrey Novikov:
>If you will do everything that users like you will end up with another IE
>clone.

I thought Mozilla is to satisfy public user needs... But based on what you say,
it would mean, that Mozilla is a product which doesn't care public user demand,
and just want to avoid to be similar to IE. That's totally wrong viewpoint.
I don't think that most Mozilla developers think the same way as you.

IMHO, Mozilla IS:
1) to satify public user needs, 
2) to be a browser, which is a good open development competitor of Microsoft IE

If you would be right, that Mozilla should not be a clone of IE, then the often
requested "image selection" would have not impemented already into Mozilla...
The "image selection" feature was a good idea in IE, and it is good to have
implemented into Mozilla. If users need some similar features what IE has, then
those features are likely good features, so should be implemented into Mozilla. 

I don't bother if Mozilla is IE clone or not, until it has popular & useful
features. Most of the users also think the same way. Probably you don't care
that millions of websites will be not able to display informational texts which
are intented to display for users, but I do care about them. 

I fight for those sites, which just used a traditional feature (ALT as tooltip)
fow years, because in facto it became standard within 4-5 years. That's why
millions of websites use it. And most websites will never change that! 
And I fight for those users, who will not be able to view those websites as they
are intended. And those users are switching back to IE to display the site
correctly. This is what you want? I would like to make people decide to change
to Mozilla, and not to change back to IE.

Many users would be glad to use an open developed browser, which is NOT
Microsoft product, and has all the good features from IE, plus has many other
good features... But unfortunately they change back to IE, if their needed or
their favourite features are not available in Mozilla.

And still my opinion is:
"Mozilla developers's job should be to accept the public demand (it is visible
that there is demand), and implement asked features."
And ALT text should be displayed as tooltip, if TITLE is not available, and that
option is turned on in Preferences.
In comment #480, Novikov claims implementing this enhancement would violate HTML
standards.  Novikov needs to read the HTML specification more carefully.  The
specification does not explicitly prohibit this enhancement.  The specification
does explicity refer to RFC 4119, which carefully describes how such a lack of
prohibition is to be interpreted.  For details, see my earlier comment #401 and
the 3rd paragraph of my earlier comment #423.  

Implementing this enhancement would NOT be contrary to HTML standards.  
re: comment 482:
quoting comment 304 (hixie):
> 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.

So yes, this is not prohibited by the HTML standard.  However, many things are
not prohibited by the HTML standard.
*** Bug 232127 has been marked as a duplicate of this bug. ***
*** Bug 233009 has been marked as a duplicate of this bug. ***
*** Bug 117089 has been marked as a duplicate of this bug. ***
*** Bug 235147 has been marked as a duplicate of this bug. ***
*** Bug 235717 has been marked as a duplicate of this bug. ***
*** Bug 239233 has been marked as a duplicate of this bug. ***
*** Bug 240153 has been marked as a duplicate of this bug. ***
*** Bug 240199 has been marked as a duplicate of this bug. ***
(In reply to comment #169)
> Oops, too many "up"s.   popupalt.xpi from
> http://www.cc-net.or.jp/~piro/xul/_popupalt.en.html

Gets a 404 for me.  From Mozilla and IE :)
(In reply to comment #492)
> > http://www.cc-net.or.jp/~piro/xul/_popupalt.en.html
> 
> Gets a 404 for me.  From Mozilla and IE :)

http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en

If it changes again just go to that sakura site... .
*** Bug 248236 has been marked as a duplicate of this bug. ***
*** Bug 252968 has been marked as a duplicate of this bug. ***
*** Bug 254155 has been marked as a duplicate of this bug. ***
(In reply to comment #496)
> *** Bug 254155 has been marked as a duplicate of this bug. ***
Wow. I am just a little user, not a developer, so most of this discussion is
greek to me. But I thought I would point out that
http://www.nytimes.com/pages/realestate/index.html uses tooltips to preview text
snippets of classified ads before you click on them. This is a very useful
timesaving feature that helps me cull hundreds of unsuitable listings each week.
I've gathered enough to know that this lack of functionality will never be
addressed in Mozilla, but I enjoy the browser otherwise. I will continue to use
MS IE to view the nytimes site (Safari also doesn't support these).  Due to bugs
in IE and Safari, I am already used to switching browsers for bug reasons, real
or otherwise.  (In reply to comment #496)
> *** Bug 254155 has been marked as a duplicate of this bug. ***
Wow. I am just a little user, not a developer, so most of this discussion is
greek to me. But I thought I would point out that
http://www.nytimes.com/pages/realestate/index.html uses tooltips to preview text
snippets of classified ads before you click on them. This is a very useful
timesaving feature that helps me cull hundreds of unsuitable listings each week.
I've gathered enough to know that this lack of functionality will never be
addressed in Mozilla, but I enjoy the browser otherwise. I will continue to use
MS IE to view the nytimes site (Safari also doesn't support these).  Due to bugs
in IE and Safari, I am already used to switching browsers for bug reasons, real
or otherwise.  
Sorry, in my previous comment I should have clarified that the nytimes.com
rollover text problem happens on R.E. search results pages, not the R.E. main
page itself. Perhaps this is not even an ALT tag problem, but something else--I
wouldn't know! In any case, the rollover text on this site isn't visible on
Mozilla but is in IE (hence my assumption). I uploaded a screenshot from IE.
It's not alt="" text. It's a javascript rollover which explicitly only works 
with browsers where one of document.all or document.layers returns true.
*** Bug 261609 has been marked as a duplicate of this bug. ***
*** Bug 266425 has been marked as a duplicate of this bug. ***
*** Bug 269187 has been marked as a duplicate of this bug. ***
(In reply to comment #504)
> *** Bug 269187 has been marked as a duplicate of this bug. ***

I wouldn't be suprised if IE regains it's few percentage points in market 
shares it lost this last year after users begin trying Firefox 1.0.  Your 
average user doesn't know or care anything about ALT or TITLE.  They just know 
that the web site works in IE and not Firefox.  They will just stick with IE.
*** Bug 269283 has been marked as a duplicate of this bug. ***
*** Bug 269456 has been marked as a duplicate of this bug. ***
(In reply to comment #47)
> 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...


I feel you make perfect sense, Manoj. I don't think it's feasable to fight Ford
by coming out with some wierd new creation, i.e., Video display rather than a
windshield, and expect to win.  The public is fickle, they want something they
feel comfortable using to start with and will make life more rewarding in some
way.  Will it benefit us to shove our viewpoints down the customers throats?

See http://www.asiaonecareers.com/st_recruit/jul2001/r0907a.htm . In part,
"In IT, it is easy to get so caught up with the bells and whistles of the latest
technology that we forget to ask how customers _benefit_ and how to communicate
it to them."
*** Bug 271226 has been marked as a duplicate of this bug. ***
*** Bug 272169 has been marked as a duplicate of this bug. ***
Summary: alt text is not displayed as a tooltip → alt text is not displayed as a tooltip over <img> (image)
I did a search for "alt img text display" prior to filing bug 272169 without
locating this bug. Sorry for duplicate.  Perhaps the search engine should first
check a most frequent duplicates list or somesuch.

That said, it seems almost insane that this single usability/feature request has
generated over 500 responses without a resolution, a workaround (such as a user
preference), or even an end in sight.

The following authoritative references describe the use of alt text in some
detail.  In no place did I read anything that would imply "displaying alt text
over image content is inappropriate."  Rather all the prose seems to permit it.
 It is the author's responsibility to ensure that the text is a suitable
alternative.
_Web Content Accessibility Guidelines 2.0_, W3C Working Draft 19 November 2004
http://www.w3.org/TR/WCAG20/#text-equiv
http://www.w3.org/TR/2004/WD-WCAG20-GENERAL-20041119/text-equiv-functional.html
http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20041119/Overview.html#img-alt

Wondering who at Mozilla/Netscape might be participating in the W3C Content
Accessibitility Group (WCAG) efforts in this area.  No one with such an
affiliation is found on the participants list.
http://www.w3.org/WAI/GL/participants.html

Thanks for the continued attention to this problem until a satisfactory
resolution is achieved.
This problem is a perfect example of the Mozilla team Nerd mentality.

alt="" text should be displayed (tooltip), this has been going on for over two
years, but some caged Nerd that has no concept of the real world has decided
 that her/she will NOT allow this feature to work in Mozilla ?

FireFox and Mozilla both suffer from "elitist" Nerds (BTW: I'm a Nerd) that
think they know better than the "masses". FYI "the masses" are their customers
and the "customer is almost always right".  FireFox and Mozilla continue to
croak on sites made for IE because of petty elite-nerds in the Gecko communiity!

 BTW: This page/site doesn't work correctly in Mozilla 1.73 and it's built by
 our Elite-Gecko-nerds ????

Fix this stupid error and move forward !!!!!!
(In reply to comment #512)
> This problem is a perfect example of the Mozilla team Nerd mentality.
> 
> alt="" text should be displayed (tooltip), this has been going on for over two
> years, but some caged Nerd that has no concept of the real world has decided
>  that her/she will NOT allow this feature to work in Mozilla ?
> 
> FireFox and Mozilla both suffer from "elitist" Nerds (BTW: I'm a Nerd) that
> think they know better than the "masses". FYI "the masses" are their customers
> and the "customer is almost always right".  FireFox and Mozilla continue to
> croak on sites made for IE because of petty elite-nerds in the Gecko communiity!
> 
> Fix this stupid error and move forward !!!!!!
> 

Bravo, Neal!
Unless the alt text tool tip problem is fixed, mozilla is destined to become
just another rusted ship wreck on the shoals of cyberspace; no more than an
interesting intellectual exercise and a hobby. 

In the way-over-long discussion about bug 25537, there have been some
work-arounds suggested. I have tried these, and at least in the context of image
maps, have found them seriously wanting. I could assume that the same would
apply to img tags, but it is dangerous to make assumptions with the behavior of
software, and I have not tested that case.

Assuming html similar to, <area shape="rect" title="x" alt="y"
coords="1,2,3,4">, and assuming graphics are turn on,

1) If "x" and "y" are identical pieces of simple text (meaning no embedded cr,
lf), then Moz and IE6 show a similar tool tip when I hover the mouse over that
part of the map.

2) If "x" and "y" are different pieces of simple text, then the two browsers
behave differently with respect to a rollover, as follows:

IE6: title="x" (no alt=)    Shows "x"
     alt="y" (no title=)    Shows "y"
     title="x" alt="y"      Shows "y" (note that alt has priority over title)

Moz: title="x" (no alt=)    Shows "x"
     alt="y" (no title=)    Shows nothing
     title="x" alt="y"      Shows "x"

This all looks very good, and yes we could, as has been suggested, in time, edit
all html to add the title= tag. However, the priority of alt over title in IE6
makes this work around less than ideal. The only common ground in the cases
given above is to refrain from using alt= in image maps, and only use title.
This does, of course, mean that there is no alternative text for people with
text-only browsers or with graphics turned off. Yes, and there is the oft-quoted
disabilities act... which of course discriminates against the majority of the
world population by not mandating alt text for every last language on the planet!

3) But there's an even bigger fly in the work-around ointment than refraining
from using alt= in image maps. The basic problem is that Moz (meaning Firefox
1.0) ignores embedded formatting in title= strings. For example, it ignores cr,
lf pairs, whereas IE6 allows them. And if the embedded formatting is missing, at
least IE6 wraps the text at 55 characters. Moz does not wrap, and truncates with
a "..." at 80 characters. This is a serious problem, and as far as I know has
not been sanctified by the W3C... and therefore is allowed, right? ;-)
Now some bright spark (one of the Moz developers, I think) pointed out that Moz
has an excellent Properties page for each and every graphic. Yes it is a good
idea, but is not designed to replace roll-overs. Who ever heard of using
right-click, click properties, as a convenient way of accessing a page? The
problem with the Properties page is that it has the whole page to itself, but
still truncates the alt text. Admittedly it shows more than 55 characters, but
it feels that if it is worth saying then it should be possible to say it in 80
characters or less. Below the point of truncation the screen looms uselessly
large and blank. Why can't the Properties page show everything without truncation?

Here's a page with an image map, where I have changed the alt= to title=. Try it
with Firefox 1.0 and with IE6. Notice that the 55-character truncation makes the
page hard to read in Firefox, particularly in the 8th frame.
http://www.telegoons.org/Canal_stills.htm
This page shows an image map that has no hyperlinks. In other words, it is not
clickable, but demonstrates, I believe, an important use of image maps. As
discussed above, the alt tag cannot be used (unless the image map is coded
multiple times for multiple browsers, which is always an unsatisfactory solution
to such problems, especially when the block of code is large, as in this example).

By way of finishing this epistle (sorry for using a word that has religious
connotations, but the reverence I see here to that apparently divine
organization, the W3C inspires its use ;-), here are some of the features I like
in Firefox 1.0: 
page tabs;
perfect automatic handling of logins and passwords (IE has never worked right
with this, presumably because MS wants you to give up in disgust and get their
Passport service); 
find (^F);

Not so great:
^N gives a new blank page with no default url. This is a waste of a page, and
inconvenient if all you wanted to do was create a tab to return to where you
were after exploring another branch of the tree. Much better to follow IE in
this, and duplicate the current url into the new page. If you don't want the
current url, nothing is lost since you can type in a new one, as you would have
done anyway had you wanted to go somewhere else.
(In reply to comment #513)
> IE6: title="x" (no alt=)    Shows "x"
>      alt="y" (no title=)    Shows "y"
>      title="x" alt="y"      Shows "y" (note that alt has priority over title)

Confirmed this IE/Win 6.0 annoyance (using Yucca's tooltip article --
http://www.cs.tut.fi/~jkorpela/html/mapalt.html).

> This all looks very good, and yes we could, as has been suggested, in time,
> edit all html to add the title= tag. However, the priority of alt over title
> in IE6 makes this work around less than ideal. The only common ground in the
> cases given above is to refrain from using alt= in image maps, and only use
> title.

So IE/Win's alt text popups have discouraged you from providing alt text at all.
You're not the first. Earlier I cited Borland ending their policy of using alt=
text for similar reasons:

"If You Are Using Lynx:

Recent versions of Lynx can handle tables enough to display Borland's Web site
coherently. However, now that Lynx represents 0% of the traffic to our site, and
since ALT text is now used as tooltips on other browsers, we can no longer
guarantee that ALT text will be in place for images."
-- http://info.borland.com/sitetools/helpfulhints.html

> This does, of course, mean that there is no alternative text for people with
> text-only browsers or with graphics turned off.

Fortunately, you've put a complete transcript at the bottom of your page, so
users of text-only browsers can enjoy "The Canal" too.

> Yes, and there is the oft-quoted disabilities act... which of course
> discriminates against the majority of the world population by not mandating
> alt text for every last language on the planet!

If an unrealistic rule mandating mandatory translations into every last language
on the planet were in the act, I doubt our legislators would've approved it.

> The basic problem is that Moz (meaning Firefox 1.0) ignores embedded
> formatting in title= strings. For example, it ignores cr, lf pairs, whereas
> IE6 allows them.

Seems to me that sequences of white space characters (including cr, lf, tab)
within attribute strings ought to be collapsed into a single space. However, I
haven't found it in the HTML specification anywhere.

> Moz does not wrap, and truncates with a "..." at 80 characters. This is a
> serious problem...

This is bug #45375.

> Why can't the Properties page show everything without truncation?

This is bug #221320.

> As discussed above, the alt tag cannot be used (unless the image map is coded
> multiple times for multiple browsers, which is always an unsatisfactory
> solution to such problems, especially when the block of code is large, as
> in this example).

Where "multiple times for multiple browsers" means "once for IE/Win, once for
everything else"?

> ^N gives a new blank page with no default url.

When I press Ctrl+N, it loads my home page as its default URL.

> This is a waste of a page, and inconvenient if all you wanted to do was
> create a tab to return to where you were after exploring another branch of
> the tree. Much better to follow IE in this, and duplicate the current url
> into the new page.

Bug #187573 asks for an option to set this behavior. 

You could also Ctrl+click a link to open a new tab into a branch of a tree, then
close the tab to return to where you were in the original tab.
I vote for this bug.

I took a long time to read through this bug. These are the arguments I found
against implementing a fix:
1. The behaviour is not described in the standard.
2. Noone would use alt= anymore and this would harm the disabled.
3. Tooltips are useless since the picture is displayed and you can see the picture.
4. Just use title= this would do the job W3C compliant.

Did I forget anything?

This is my opinion
1. This is a religion not an argument. The question is if it does harm the
standard. And in my opinion it doesn't. What is important is that compliant code
does show correctly.  I don't believe that it is incorrect when tooltips appear
without title= Why should somebody rely on that? That would be stupid because >
90% of the usere doe see it. Thus add title='' and everythig is compliant and works.
2. It's the other way round. alt= is used because it creates tooltips and
disabled can profit from this. The only good point is with placeholders like
'------------' which you would not like to show up. But there would be a
compliant solution, just add title=''. When there is information in alt= why
should it be hidden? Tooltips are nothing permanent. They appear when you are
searching for it! I doubt that there is a single author who does not know about
title= and would not use alt for disabled people because others would see tooltips.
3. You have never been in these thousands of forum pages with all these icons?
Oh you know the meaning of all these icons? It is very very helpfull to have the
tooltips. But unfortunately Firefox does not show them :-( Believe me or believe
me not. It does make a big difference. I can perfectly see but not all of these
millions of icons are self explaining! And unfortunately not all of the authors
are my buddies and many of them use third party tools to create the pages. It
would be a great step in the right direction when these tool developers would
change their tools. Do they?
4. Yes this would fix it if I would be the author of all pages I visit. But, you
didn't expect that, did you, I'm not.

Someone called the developers stubborn. And yes sometimes this might have good
reasons. But it is not something positive by default. Sometimes it's simply
stupid and ignorant.

I don't use IE because of all the security issues. Firefox has better features,
too. But when IE would overcome it's deficiencies and Gecko brothers still
insist in their shortcomings, why should anyone use Firefox/Gecko anymore? I
know that many don't care. But I do. It would be a pitty.

Just my opinion
IE6: title="x" (no alt=) Shows "x"
alt="y" (no title=) Shows "y"
title="x" alt="y" Shows "y" (note that alt has priority over title)

I don't ask for this behaviour. This IS a bug in IE. I ask for

alt="y" (no title=) Shows "y"
title="x" alt="y" Shows "X" 
title="" alt="y" Shows nothing 
(In reply to comment #516)
> I don't ask for this behaviour. This IS a bug in IE. I ask for

It seems people think that parsing it wrong because IE does it is actually good.
But there is no point, no point _at all_ to say that it will actually improve
the internet, or what nonsense I am hearing...

> alt="y" (no title=) Shows "y"
> title="x" alt="y" Shows "X" 
> title="" alt="y" Shows nothing 

That's the true discussion. Is that a feature, or does it not comply to the W3C?
*** Bug 272839 has been marked as a duplicate of this bug. ***
*** Bug 274154 has been marked as a duplicate of this bug. ***
Does anybody use Ebay with Firefox, i.e. buy and sell stuff? Do you know the
meaning of all the icons in MyEbay?

The argument that you don't need the tooltips because you see the picture is not
an argument! Use Ebay, use news groups use any page with multiple icons and you
know what I mean. There are millions of icons and I don't know them and I doubt
that I want to lear all of them by heart.

Do you tell Ebay that they should change their shop to comply your standards?
(No, it's not W3C, it's yours. It's not forbidden to show tool tips for ALT.)

Currently this bug is the number one annoyance while surfing with Firefox (o.k.
it suggest itself since there are not many :-)
(In reply to comment #520)
> Does anybody use Ebay with Firefox, i.e. buy and sell stuff? Do you know the
> meaning of all the icons in MyEbay?
> 
> The argument that you don't need the tooltips because you see the picture is not
> an argument! Use Ebay, use news groups use any page with multiple icons and you
> know what I mean. There are millions of icons and I don't know them and I doubt
> that I want to lear all of them by heart.
> 
> Do you tell Ebay that they should change their shop to comply your standards?
> (No, it's not W3C, it's yours. It's not forbidden to show tool tips for ALT.)
> 
> Currently this bug is the number one annoyance while surfing with Firefox (o.k.
> it suggest itself since there are not many :-)
> 

...and it's not likely that Ebay, et al, will change to using title= (in
addition to the obligatory alt=) because the hugely popular IE browser does not
show the title= tag contents if there's an alt= tag.

As one correspondent recently said, a lot of major sites are dispensing with the
alt= tag because of problems such as the one Moz Firefox has (not showing alt
text when the image is present or not present) and the one that IE has when
sites apply the title= fix suggested by the Firefox adherents (not showing the
title text when there is an alt= tag). [Sorry to use a word with religious
conotation to describe the otherwise quite brilliant individuals working on the
Firefox project, but that's the way it seems to me as a relative outsider].

I've looked at the W3C rules on this topic too, and can only conclude that since
the W3C is somewhat vague on it, that the real issue must be something other
than claimed reverence for W3C. Perhaps it's just plain orneriness and
stubbornness, and a misguided refusal to back down in the face of an
overwhelming number of complaints about this problem in Firefox.

Unless there's a positive change in the thinking of the Firefox developers over
compatibility issues such as this one, I predict that IE will continue to be the
browser of choice for most people. And this comes from someone who in most other
respects *loves* what the Firefox developers have done. Why not finish the job
guys, so that we can recommend Firefox to our friends without *any* reservations
whatsoever? Right now I can only say, "It's a great browser, but..."
I have voted for this bug and agree with many recent comments that it should be
fixed.  However, as far as I can tell without rereading all the text on this bug
again and checking the CC list, the people cc'd on this bug are all people who
believe that this should be fixed.  For example, Ian Hickson, who posted an
early and uncompromising WONTFIX, is not cc'ed here.  So posting arguments here
does not help much.

If we are to change anybody's mind then the argument needs to be carried out in
another forum.  I don't know where that is -- perhaps one of the newsgroups?
(In reply to comment #522)
> I have voted for this bug and agree with many recent comments that it should 
> be fixed.  However, as far as I can tell without rereading all the text on 
> this bug again and checking the CC list, the people cc'd on this bug are all 
> people who believe that this should be fixed.  For example, Ian Hickson, who 
> posted an early and uncompromising WONTFIX, is not cc'ed here.

Yes I am. I'm the QA Contact. I read every frigging comment added to this 523+
comment bug. It's just that nobody has said anything new for the last 2 years.
The reasons for this bug to be WONTFIXed, just like it has been in EVERY SINGLE
BROWSER apart from WinIE, were laid out years ago and are still valid.
For the record, not everyone on the CC list thinks it should be fixed.

I recognise other addresses and know they agree this should be WONTFIX too.

I don't know why I'm still CC'd, maybe some twisted form of self-loathing,
or maybe just to see which old arguments people are using these days. (Wow, you
can give yet another example of a site that misuses ALT text and relies on
IE-specific behaviour? Now you've pointed that out it MUST get fixed!)


I agree with comment #522 that re-stating the same arguments here won't help.
This bug is already far too long so that no-one new to it will ever read it all
and understand why it won't be changed.

As for #521, have you actually tried asking eBay to add title tags? Or are you
just making assumptions and using them as facts to back up your case?
It might be time to remind people once more of the PopupAlt extension:

http://piro.sakura.ne.jp/xul/_popupalt.html.en
(In reply to comment #523)
> Yes I am. I'm the QA Contact. I read every frigging comment added to this 523+
> comment bug. It's just that nobody has said anything new for the last 2 years.
> The reasons for this bug to be WONTFIXed, just like it has been in EVERY SINGLE
> BROWSER apart from WinIE, were laid out years ago and are still valid.

Precisely.

Frankly I finbd it laughable that something as basic as a missing tooltip would
seriously prevent the mass adoption of Firefox.
> Frankly I finbd it laughable that something as basic as a missing tooltip
> would seriously prevent the mass adoption of Firefox.
 
Don't laugh too hard. *Something* is preventing the "mass adoption" of Firefox
1.0, and you need to ask what it is. Could it be tooltips by any chance? How do
you know it's not tooltips? What do the 80.95% who use IE 6.0 think about
Firefox 1.0? Many products fail in the marketplace due to the smallest things. 

In any case, here's tha latest figures, as reported by the BBC news:

1 - Microsoft IE 6.0: 80.95%
2 - Microsoft IE 5.0: 4.18%
3 - Microsoft IE 5.5: 3.66%
4 - Mozilla Firefox 0.10: 2.79% 
5 - Mozilla 1.x: 2.77%
6 - Mozilla Firefox 1.0: 1.79% <----
7 - Opera 7.x: 1.29%

Unlike Ian Hickson I have not read every #@!%$ post on this bug. I did however,
start at the begining and read as far as I could stomach it, which was about
half way.

The problem, I think is that the people who "couldfix" but WONTFIX are not
really properly considering many of the points raised. They are reasing only so
far and then thinking that this is just a repeat of some earier point. In some
cases that is certainly the case, which just goes to show the depth of the problem. 

The major problem is that the WONTFIX camp are not interested in building a
browser that is the most use to the most people. Insetead they seem to be hell
bent on clinging to a fundamentalist interpretation and implementation of the
W3C scriptures, even if said scriptures are sometimes vague, rather than
producing a browser that will work for Ebay, my banks, BBC new, and the list
goes on and on. What they are engaged in is no more than an ivory tower
intellectual exercise with the rest of us as unpaid patsies to test their work.

Earlier in the discussion the WONTFIX camp said "Use title= and your problem
will go away". It did not, since IE will not show the title= tooltip if there is
an alt=string.

The lack of a multi-line capability in the Firefox title and alt tooltips is
absolutely unconscionable. Why why why? W3C does not prohibit this, so maybe
it's a case of NIH (not invented here)? 

Final point: The reverence for W3C among the WONTFIXIES tosses out the
tome-honoured iterative approach to software writing. Something may seem like a
good idea in theory, but if it stinks in practice, then we go back and improve
the spec and update the practice.

Keep in mind the old saying that a committee is a life form with six or more
legs, but no brain. 
> The reasons for this bug to be WONTFIXed, just like it has been in EVERY SINGLE
> BROWSER apart from WinIE, were laid out years ago and are still valid.

This remark shows a serious misconception. The phrase "every single browser
apart from IE" leads to believe that the vast majority of browsers out there
would not render tooltips just like FireFox/Mozilla doesn't.

In reality it's just the other way round:

>In any case, here's tha latest figures, as reported by the BBC news:
>1 - Microsoft IE 6.0: 80.95%
>2 - Microsoft IE 5.0: 4.18%
>3 - Microsoft IE 5.5: 3.66%

That makes a stunning 88,79 percent for IE. So if one leaves the ivory tower of
pure science and accepts reality the phrase should read

"nine out of ten browsers (almost every single browser except for
FireFox/Mozilla) render tooltips". 
I would rephrase Oliver's conclusion as follows:

"ninety precent of installed browser base renders wrongly <alt> tags as tooltips
even when the standards compliant <title> tag is present".

Which means I am 100% for the web standards. But still, I would accept rendering
<alt> tags as tooltips when <title> is not present.
(In reply to comment #528)
> >In any case, here's tha latest figures, as reported by the BBC news:
> >1 - Microsoft IE 6.0: 80.95%
> >2 - Microsoft IE 5.0: 4.18%
> >3 - Microsoft IE 5.5: 3.66%
> 
> That makes a stunning 88,79 percent for IE. So if one leaves the ivory tower of
> pure science and accepts reality the phrase should read
> 
> "nine out of ten browsers (almost every single browser except for
> FireFox/Mozilla) render tooltips". 

We're lying with statistics now? One browser out of ten renders alt text as
tooltips, in a survey of ten Web browsers (Internet Explorer/Win, Internet
Explorer/Mac, Mozilla, Netscape, Firefox, Opera, Konqueror, Safari, NetCaptor,
and iCab).

Even correcting your claim to "The browser with 90% market share (unlike almost
every other browser including Firefox/Mozilla) renders alt text as tooltips",
the evidence still doesn't support that conclusion. "Microsoft IE 5.0" includes
Internet Explorer 5.0 for the Mac, so really you can only estimate between 85%
and 90%.
(In reply to comment #530)
> We're lying with statistics now? One browser out of ten renders alt text as
> tooltips, in a survey of ten Web browsers (Internet Explorer/Win, Internet
> Explorer/Mac, Mozilla, Netscape, Firefox, Opera, Konqueror, Safari, NetCaptor,
> and iCab).

Even if there were 999 out of 1000 browsers that did it like Firefox, it doesn't
matter.  Because the 1 (IE) commands 90% of the market!  Beat Microsoft at it's
own game.  Mimic the competition and then add value by making it better.
(In reply to comment #531)
> Even if there were 999 out of 1000 browsers that did it like Firefox, it doesn't
> matter.  Because the 1 (IE) commands 90% of the market!

84.61%-88.79% of the market, as comment #530 just pointed out.

> Beat Microsoft at it's own game.  Mimic the competition and then
> add value by making it better.

I prefer our current plan of making a better browser to begin with, instead of
repeating Microsoft's mistakes.
>We're lying with statistics now? One browser out of ten renders alt text as

Are we?

If California introduces a law that says that every car manufacturer has to have
one model out of ten that is zero emission, would you then claim that 10 percent
"of all cars" are zero emission, even if this one model isn't bought by anyone
so it's market share is minimal?

It's _only_ the body of installed browsers that counts, not the number of
different browser products that a user can choose of - especially if you
consider that _one_ browser is already installed on practically all user's
operating system (What a conincidence! That browser has the biggest market
share...).

And next week when some new now-unheard-of browsers are introduced your figures
suddenly change even on the user's side nothing has changed? The number of
browsers to choose from is no statistical figure of _any_ value. All that counts
is the installed base.

>tooltips, in a survey of ten Web browsers (Internet Explorer/Win, Internet
Explorer/Mac, Mozilla, Netscape, Firefox, Opera, Konqueror, Safari, NetCaptor,
and iCab).

And how do you count AOL/Netscapes next browser? They have decided to integrate
IE into it. And guess why? For compatibility reasons. And that does not mean
compatibility to the standard, Mozilla is pretty good there. No, it's
compatibility to the installed web sites on the planet...

It's not good producing a car that sticks 100% to government standards if that
means it gets incompatible to most of the roads... Because sometimes you find
that roads are not built to standard, even they should be. Is it a clever
strategy not to adapt one's car to reality's road and instead just claim "Foul!
Please fix your roads so that I may use my car here..."
> Earlier in the discussion the WONTFIX camp said "Use title= and your problem
> will go away". It did not, since IE will not show the title= tooltip if there 
> is an alt=string.

This is untrue. IE only shows "alt" for tooltips if it is the only attribute
present, title attributes correctly override alt="":

   http://www.hixie.ch/tests/adhoc/html/flow/img/003.html
   http://www.hixie.ch/tests/adhoc/html/flow/img/004.html

Please don't misrepresent the truth in an attempt to convince people to change
their mind.


> The lack of a multi-line capability in the Firefox title and alt tooltips is

...completely irrelevant to this bug, please stick to one issue per bug.


> Final point: The reverence for W3C among the WONTFIXIES tosses out the
> tome-honoured iterative approach to software writing. Something may seem like 
> a good idea in theory, but if it stinks in practice, then we go back and 
> improve the spec and update the practice.

The idea doesn't "stink in practice" -- there are numerous examples (cited in
this very bug!) of where Mozilla's policy (which is also the policy of EVERY
SINGLE OTHER BROWSER out there except WinIE) has caused sites to improve their
accessibility story.

And yes, WinIE has the majority marketshare, so most of the installed base has
this bug. I never denied this, indeed I have used it as an example for why many
sites have poor accessibility (misusing alt=""). My point is that the majority
of Web browser _vendors_, of Web browser _experts_, if you will, agree with
Mozilla on this issue. (Including Microsoft experts, given that MacIE didn't
show alt attributes for tooltips either.)


> Keep in mind the old saying that a committee is a life form with six or more
> legs, but no brain. 

This is no committee, it's a meritocratic elite dictatorship. In fact, listening
to everyone's input, such as yours, is what would make this a committee.

I agree that committee-driven design creates poor products.
It has been asserted that MS may be pressured to update IE to behave correctly
with respect to the ALT tag if Mozilla and other browsers stick to the correct
behaviour and don't diverge from the standard.  But Ian has pointed out that IE
behaves correctly with regard to TITLE overriding ALT, so how can this pressure
ever be exerted?  Pressure on IE would come from a site that is coded correctly
and performs correctly in Mozilla but not in IE.  A correctly coded site will
either have or not have TITLE; if it has TITLE, IE behaves correctly.  If it
does not, IE displays a tooltip that it should not.  This is not likely to cause
any pressure on IE to change.

If it were the case that a site coded for disabled users would function
incorrectly with IE, then I could see MS ultimately bowing to complaints and
changing the way IE works.   As it is, I don't understand how the mechanism of
Mozilla-compliance forcing MS-compliance can work.

If someone who believes this approach could be effective would explain this, I'd
appreciate it.  I am not trying to be obstreperous, but I really don't
understand this point.
The discussions on this bug seems to slide off topic fast, with bickering on
what is termed as statistics, 10 or 90%, and so on.

It seems worrying that an issue that sparks so many responses is left as a firm
wontfix.
I know sweet little about html and W3. But although I love firefox to bits, I
and many colleagues are slowly concidering going back to IE, because of too many
problems in showing pages correctly/sufficiently. Alt tooltip is the major
culprit in this respect.
(In reply to comment #534)
> > Earlier in the discussion the WONTFIX camp said "Use title= and your problem
> > will go away". It did not, since IE will not show the title= tooltip if
> > there is an alt=string.
> 
> This is untrue. IE only shows "alt" for tooltips if it is the only attribute
> present, title attributes correctly override alt="":

Sorry Ian, I forgot to say the following: In an image map, IE6 will not show the
title tooltip if an alt tooltip is present. This is why some of the image maps I
use on the seb use title but not alt. Afterall, my website has to work with the
majority of browsers in use, and IE6 is more than 80%. Clearly, however, this
behavior of IE6 with image maps is a *bug* no matter what shade of cloth one
might wear, since it is inconsistent with its behavior in the image case.

Anyway, it turns out that things are a lot stranger than I first thought, and
even though Firefox 1.0 breaks a huge number of important websites due to its
handling of the alt= tag (which is really my only major problem with Firefox),
Firefox 1.0 is at least consistent between images and image maps in respect of
alt= and title= tags.

Here's my more complete test results:
                                   FF1.0  IE6  Lynx  NS7.1  FP2K*
img with alt="a",    no title tag    -    [a]   a     -      a        
img with alt="a",    title=""        -     -    a     -      a
img with alt="a",    title="t"       t     t    a     t      t
img with no alt tag, title="t"       t     t    t     t      t
img with alt="",     title="t"       t     t    t     t      t

                                         FF1.0  IE6  Lynx  NS7.1  FP2K*
image map with alt="a",    no title tag    -    [a]   %     -      a        
image map with alt="a",    title=""        -     a    %     -      a
image map with alt="a",    title="t"       t    (a)   %     t      a
image map with no alt tag, title="t"       t     t    %     t      t
image map with alt="",     title="t"       t     t    %     t      t

___________________
*Front Page 2000 Preview mode
( ) is the case that you contested, and quite rightly so, for images, not for
image maps.

> Please don't misrepresent the truth in an attempt to convince people to change
> their mind.

It was a misunderstanding. Please see discussion above.

> This is no committee, it's a meritocratic elite dictatorship. In fact,
> listening to everyone's input, such as yours, is what would make this a
> committee. 

Interesting...and this forum is equivalent to the committee level in the design
process, dictatorship or not. 

Here's my test code:
http://telegoons.org/test_of_alt_and_title_tags.htm

Now if only Firefox would implement the one behavior marked with [ ] in the
tables above, and you could shut down this stupid bug thread, and get a life
again... ;-) There is a huge amount of agreement on this (there's that committee
mentality again). 

And pushing your dictatorship model a bit (your word, not mine), if enough
people move away from Firefox to say Altfirefox (any takers?) then the dictator
has effectively suffered the sort of demise that catches up with most such
individuals.
 
> Sorry Ian, I forgot to say the following: In an image map, IE6 will not show 
> the title tooltip if an alt tooltip is present. This is why some of the image 
> maps I use on the seb use title but not alt.

Oh good, yet another IE bug.


> Here's my more complete test results:
>                                    FF1.0  IE6  Lynx  NS7.1  FP2K*

Note that Lynx isn't showing tooltips at all, so is largely irrelevant here.
Lynx _should_ be showing alt text (even when alt="", it's a bug that it isn't)
and indeed a large part of why this bug has been WONTFIXed is that IE's
behaviour encourages people to put text in alt="" attributes that _should_ be
put in title="" attributes and should _not_ be in alt="" attributes, since it
would be inappropriate in those cases.


> > This is no committee, it's a meritocratic elite dictatorship. In fact,
> > listening to everyone's input, such as yours, is what would make this a
> > committee. 
> 
> Interesting...and this forum

This isn't a forum. It's a bug database.


> is equivalent to the committee level in the design process, dictatorship or 
> not. 

It _would_ be equivalent, if comments in Bugzilla had much bearing on whether
bugs got fixed or not. As you are finding, they don't.


> And pushing your dictatorship model a bit (your word, not mine), if enough
> people move away from Firefox to say Altfirefox (any takers?) then the 
> dictator has effectively suffered the sort of demise that catches up with most
> such individuals.

Yes, the beauty of Free software is that anybody is Free to take the program and
make a variant that does what _they_ want. That's what Free software is all
about -- giving the users the Freedom to make their computers do what they want,
not what the vendors wants.

You are very welcome to make a derivative product and see if people prefer it to
Mozilla's product. If the comments made earlier are right and the lack of
tooltips on images that don't have a title attribute but do have an alt
attribute is the main reason why Firefox only got 10 million downloads in the
last month instead of 500 million, then your derivative product will most likely
be a roaring success.


> There is a huge amount of agreement on this

Not really. This bug has only 30 votes and barely 100 duplicates. In contrast,
the MNG bug has over 700 votes, and Mozilla drivers still have no intention of
letting MNG be turned on, and bug 22274 has over 130 duplicates, and is still
INVALID, with there not being any intention from the Mozilla drivers of ever
"fixing" it.

No, this bug doesn't have a notable amount of agreement. In fact of the authors
of its 600 comments there are about as many people arguing for it as there are
arguing against it, and several of the original proponents of this bug have
since changed their mind (while none of those saying it should stay WONTFIXed
have ever gone the other way).
A personal appeal to Hixie:

We made Mozilla support document.all (bug 248549 where you also were the QA)
which is an even bigger Microsoft heresy against the standards. Let us be
consistent and do the same for alt text tooltips in the case of no title text.
It seems the tide flows thia way, we no longer try to live in an ivory tower of
W3C standards without any regars for what is actually used on web pages.

I do agree that should be probably allowed only in the quirks mode (like the
undetected document.all). If you feel really uneasy about this, let us make a
hidden pref for this and turn it off by default. This way at least the persons
who really want this "feature" as well as distributors of mozilla derived
browsers (if they want) can easily switch this on. 

As this bug is horribly bloated I would consider opening a new one. The reason I
am loth do that at this moment, before we reach a consensus, is apprehension
that you (Hixie) or someone else would dupe it against this bug in no time.
> We made Mozilla support document.all (bug 248549 where you also were the QA)
> which is an even bigger Microsoft heresy against the standards.

It's not a bigger "heresy", as you put it. document.all was already supported by
browsers other than IE, and caused significant problems on many high-profile
sites. None of that applies to this bug.


> It seems the tide flows thia way, we no longer try to live in an ivory tower 
> of W3C standards without any regars for what is actually used on web pages.

This really isn't about being in an ivory tower, it's mostly about promoting
accessibility. See the earliest comments on this bug for more details.


> As this bug is horribly bloated I would consider opening a new one. The reason 
> I am loth do that at this moment, before we reach a consensus, is apprehension
> that you (Hixie) or someone else would dupe it against this bug in no time.

There's no point opening a new bug. This "bug" is not going to be "fixed", since
Mozilla's behaviour is exactly as designed and as intended.
I wonder if the choice to misuse ALT isn't a matter for the web page creators'
own consciences.  

If Mozilla sees itself as a "church of the righteous" with mission to make
others repent then perhaps that should be stated on it's website as one of the
goals:

"To make web page creators behave properly."

If, on the other hand, the mission is to help people to traverse the web (I
wanted to say "explore" . . . ) then perhaps this issue could be addressed with
more regard for the people who have to browse websites which are imperfectly
compliant and less regard for a quasi-religious standards crusade.

Regards,

Tim
(In reply to comment #534)
534> Here's my more complete test results:
534>                                    FF1.0  IE6  Lynx  NS7.1  FP2K*
...
534> img with alt="",     title="t"       t     t   *t*    t      t
[*emphasis* mine]

538> Lynx _should_ be showing alt text (even when alt="", it's a bug that it
538> isn't) ...

No way! Lynx overriding alt with title? I don't believe it, but I'll check.

No, loading http://telegoons.org/test_of_alt_and_title_tags.htm in my Lynx
2.8.4, Lynx shows nothing for your alt="" title="t" test.

Using your test page, these are the results I get:


** alt and title on image **
 
                | "a"  -  | "a" ""  | "a" "t" |  -  "t" |  "" "t" |
-- popup text --
Amaya 8.7       |    -    |    -    |    -    |    -    |    -    |
Arachne 1.70    |    -    |    -    |    -    |    -    |    -    |
Firefox 1.0     |    -    |    -    |    t    |    t    |    t    |
HotJava 3.0     |    a    |    a    |    a    |    -    |    -    |
iCab 2.98       |    -    |    -    |    t    |    t    |    t    |
   Note: iCab presents title as message on status bar, not popup
IE/Win 6.0 SV1  |    a    |    -    |    t    |    t    |    t    |
Mozilla 1.7.3   |    -    |    -    |    t    |    t    |    t    |
Netscape 4.80   |    a    |    a    |    a    |    -    |    -    |
Netscape 7.20   |    -    |    -    |    t    |    t    |    t    |
Opera 7.54      |    -    |    -    |    t    |    t    |    t    |

-- image replacement --
Amaya 8.7       |    a    |    a    |    a    |  img    |    -    |
Arachne 1.70    |   [a]   |   [a]   |   [a]   |  [IM]   |   [ ]   |
Firefox 1.0     |   [x]   |   [x]   |   [x]   |   [x]   |   [x]   |
HotJava 3.0     |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
iCab 2.98       |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
IE/Win 6.0 SV1  |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
   Note: [#] whether "Show image download placeholders" checked or not
Lynx 2.8.4      |    a    |    a    |    a    |    t    |    -    |
Mozilla 1.7.3   |    a    |    a    |    a    |   [#]   |    -    |
Netscape 7.20   |    a    |    a    |    a    |   [x]   |    -    |
Opera 7.54      |   [a]   |   [a]   |   [a]   | [Image] |    -    |

** alt and title on image map **
 
                | "a"  -  | "a" ""  | "a" "t" |  -  "t" |  "" "t" |
-- popup text --
Amaya 8.7       |    -    |    -    |    -    |    -    |    -    |
Arachne 1.70    |    -    |    -    |    -    |    -    |    -    |
Firefox 1.0     |    -    |    -    |    t    |    t    |    t    |
HotJava 3.0     |    a    |    a    |    a    |    -    |    -    |
iCab 2.98       |    -    |    -    |    t    |    t    |    t    |
   Note: iCab presents title as message on status bar, not popup
IE/Win 6.0 SV1  |    a    |    a    |    a    |    t    |    t    |
Mozilla 1.7.3   |    -    |    -    |    t    |    t    |    t    |
Netscape 4.80   |    -    |    -    |    -    |    -    |    -    |
Netscape 7.20   |    -    |    -    |    t    |    t    |    t    |
Opera 7.54      |    -    |    -    |    t    |    t    |    t    |

-- image replacement --
Amaya 8.7       |   img   |   img   |   img   |   img   |   img   |
Arachne 1.70    |  [IM]   |  [IM]   |  [IM]   |  [IM]   |  [IM]   |
Firefox 1.0     |   [x]   |   [x]   |   [x]   |   [x]   |   [x]   |
HotJava 3.0     |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
iCab 2.98       |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
IE/Win 6.0 SV1  |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
Lynx 2.8.4      |   [*]   |   [*]   |   [*]   |   [*]   |   [*]   |
   Note: [*] = "[USEMAP: CD-icon.gif]"
Mozilla 1.7.3   |   [#]   |   [#]   |   [#]   |   [#]   |   [#]   |
Netscape 7.20   |   [x]   |   [x]   |   [x]   |   [x]   |   [x]   |
Opera 7.54      | [Image] | [Image] | [Image] | [Image] | [Image] |
reply to  #473 From Robin Lionheart  
It's not the main site www.ebay.com where the problem is. It's on My.eBay.com
All those icons describing the status of your articles. Who needs www.ebay.com?
But my.ebay.com (and it's daughters like my.ebay.de etc.) is definitely one of
the most used sides in the world.

reply to  #524 From Jon Wakely
Yes I wrote ebay that they should use title= and alt= instead of alt= (I made
some more words :-) I did not get an answer yet.

reply #525 From Phil Randal
I will try

   http://piro.sakura.ne.jp/xul/_popupalt.html.en

the link mentioned before in #117 From Ian 'Hixie' Hickson did not work and I
could not find it here

   https://addons.update.mozilla.org/extensions/

What is the reason that it is not on mozilla.org?

reply #526 From Bradley Chapman
It's might be "laughable" for you, but tooltips which tell you what icons mean
are very important for users. Maybe not for powerusers who know the icons by
heart but for the majority of users. There are so many sides, not only
my.ebay.com but all these forum sides. It will not make the difference between
10 Million and 50 Million downloads but it does make a difference, that's for
sure. But who knows the numbers?

To everyone who is in favour of WONTFIX:
What exactly are the arguments against the option in [] in #537 From Alastair
Roxburgh?
                                      FF1.0  IE6  Lynx  NS7.1  FP2K*
   img with alt="a",    no title tag    -    [a]   a     -      a        

This is the only change we ask for.

Does it harm the usage of alternative texts for disabled and how? 

As far I understand the W3C text this behaviour is not forbidden, right? What
about downward compatibility? title= is relatively new.

When does it harm anybody when a tooltip with "a" shows up? And when the author
does not like it, is it a big problem for somebody? Would it be much to ask the
author to use title=""? Sides without title="" might show unwanted tooltips. Do
they really hurt? I think no. Sides without title= show not tooltips. Does that
hurt? Definitely yes!

I read through this bug for hours but I could not find any answers on this
questions. Maybe it's here and I simply did not understand ... Any quote?

I promise when I understand your answers (and I will try hard) and popupalt
works I will never show up here again ...


I tested Popup Alt Extension and here are the results. Results which don't
reflect the desired real world and W3C compliance behaviour are marked with |*

There is only two line without |*! 
 
**** alt and title on image ****
                | "a"  -  | "a" ""  | "a" "t" |  -  "t" |  "" "t" |

-- popup text --
Firefox 1.0     |*   -    |    -    |    t    |    t    |    t    |
FF with Extens. |    a    |*   a    |    t    |    t    |    t    |
IE 6            |    a    |    -    |    t    |    t    |    t    |

-- image replacement -- text on screen / tooltip
Firefox 1.0     |  a / -  |  a / -  |  a / t  |  - / t  |  - / t  |
FF with Extens. |  a / a  |* a / a  |  a / t  |  - / t  |  - / t  |
IE 6            |* - / a  |* - / -  |* - / t  |  - / t  |  - / t  |


**** alt and title on image map ****
                | "a"  -  | "a" ""  | "a" "t" |  -  "t" |  "" "t" |
-- popup text --
Firefox 1.0     |*   -    |    -    |    t    |    t    |    t    |
FF with Extens. |    a    |*   a    |    t    |    t    |    t    |
IE 6            |    a    |    a    |*   a    |    t    |    t    |

-- image replacement -- text on screen / tooltip
Firefox 1.0     |* - / -  |* - / -  |* - / t  |  - / t  |  - / t  |
FF with Extens. |* - / a  |* - / a  |* - / t  |  - / t  |  - / t  |
IE 6            |* - / a  |* - / a  |* - / a  |  - / t  |  - / t  |
Our mission _does_ include making Web developers write better code:
   http://www.mozilla.org/about/

Showing alt attributes in tooltips would encourage authors to only use alt
attributes for tooltips, which is bad because when the tooltip and the alternate
text should be different (often), then it reduces the quality of the alternate
text, reducing the experience for people who don't have images.

Now tell me this: Why are you campaigning to have Mozilla break their code
instead of campaigning for Microsoft to fix theirs?
>Our mission _does_ include making Web developers write better code:
>   http://www.mozilla.org/about/

Frankly, in this page I cannot find any text that says that Mozilla _forces_ Web
developers to write better code. It only says that Mozilla is an advocate for
Standards and that Mozilla enables developers to write better code. But it
doesn't say that it forces them to do so by ignoring code that is not 100% pure
compliant and by not forgiving any errors or misinterpretations of the standards.

But I find something different there that is very important and that I want to
draw your attention to:

[...] We believe and practice the canons of open source development: release
early and often, listen to your users, [...]

Well, do you listen to your users? At least not here.

But anyway, the discussion about "writing better code" completely misses the
point. These days, web sites are no longer "written" by the Web site developers
or publishers. It was the original intention of HTML to be a "markup language",
which means that HTML ought to be _pure text_, that can be read with plain eyes,
that contains markup tags that help rendering agents to present it beautifully.

But theses days are long gone. Today, in reality, even within the Standards,
HTML is no longer a markup language for text but actually a full blown page
description language that can _only_ be read and understood by rendering agents.

Today, HTML pages are generated fully automatically by software. No Web
developer has his or her hands on the code anymore. The quality of the code
relies practically 100% on the quality of the web development software, which is
notoriously known for its bad code quality, no matter from which vendor it comes.

>Showing alt attributes in tooltips would encourage authors to only use alt
>attributes for tooltips, which is bad because when the tooltip and the 

Why would this step, by a browser with < 10 percent market share, "encourage"
authors? You have written this claim numerously, but to my knowledge never
presented compelling evidence why this would be so.

>alternate
>text should be different (often), then it reduces the quality of the alternate
>text, reducing the experience for people who don't have images.

Tooltips are something totally different than the images themselves. So for
users _with_ images there are also two different "experiences" at the same time.
Now why would that reduce the "experience" of users without images? To get a
description of the image and the tooltip in my view does not reduce anything.
It's just the textual expression of the experience that users with images get.

>Now tell me this: Why are you campaigning to have Mozilla break their code
>instead of campaigning for Microsoft to fix theirs?

First, it would _not_ break Mozillas code if it adapts to reality's websites.
Not at all. So maybe he does it because Microsoft's browser is fit for reality's
websites and Mozilla isn't (in regards to tooltips) ?
> Frankly, in this page I cannot find any text that says that Mozilla _forces_ 
> Web developers to write better code.

We're not forcing anyone to do anything. Merely encouraging, by treating the
markup as the specs intended them to be interpreted.


> Well, do you listen to your users? At least not here.

We're listening. If we weren't, you'd be being ignored. I'm clearly not ignoring
you! We just disagree.


Regarding your point about pages being written by software and not by hand, it
is irrelevant. It doesn't matter if the software gets fixed or the authors get
fixed, so long as something gets fixed. There are several examples in the
comments of this bug alone that show sites that have been affected by this and
have been fixed.


Finally, note that your comments indicate that you still don't understand the
point of the "alt" attribute. It isn't supposed to give a description of the
image. It is supposed to give text equivalent to the image. Please read up on
the matter before asking us to change our behaviour.


Out of interest, could you point to the specific sites that are depending on
this IE bug to such an extent that your experience with Firefox is hurt? Thanks.
>We're not forcing anyone to do anything. Merely encouraging, by treating the
>markup as the specs intended them to be interpreted.

Of course you force. Instead of making Mozilla compatible with reality, you want
to change reality instead of Mozilla.

And: Your interpretation of the Standards is just that. Your interpretation. As
several other authors have stated, rendering tooltips is _not_ forbidden by the
standards, so using them on websites is _not_ bad code.

>We're listening. If we weren't, you'd be being ignored. I'm clearly not
>ignoring you! We just disagree.

WONTFIX means you're not listening and you do ignore us (it's not about me, it's
about _us users_, as much as "you" doesn't mean you in person, but "the team").
Don't forget the _numerous_ people, numbering by the hundreds, who have been on
CC on this bug and have withdrawn after reckognizing that they are completely
ignored by the Mozilla team. You tend to count these people as fellows who
changed their mind, but that is not the case. These people are just disappointed.

>Regarding your point about pages being written by software and not by hand, it
>is irrelevant. It doesn't matter if the software gets fixed or the authors get
>fixed, so long as something gets fixed. There are several examples in the

No. You bark at the wrong place. You face _your users_ and _web site developers_
while in reality it is the producers of code generation engines that should be
evangelized. This bug and it's history shows that you shove away the wrong
people. Neither _Mozilla users_ nor _website developers_ have any saying in the
way website code is produced! And even if you win website developers, they
cannot change the way the coding engines code... Only on very very big websites
where the company behind it writes it's own engine you can be succesful,
otherwise you _will_ lose this battle.

>comments of this bug alone that show sites that have been affected by this and
>have been fixed.

I do not deny that some web sites did make some changes, and I do applaud them.
But there are so many sites out there that Mozilla cannot render correctly. Too
many.

>Finally, note that your comments indicate that you still don't understand the
>point of the "alt" attribute. It isn't supposed to give a description of the

And your comments indicate that you do not understand the way that tooltips are
use on reality's websites. It is totally irrelevant what W3C committe members at
one point in history _supposed_ alt to be used for. It has not materialized in
real world (as so many good concepts of the W3C...) and reality's browsers have
to cope with reality's web and _not_ with the intentions of some committee members.

>Out of interest, could you point to the specific sites that are depending on
>this IE bug to such an extent that your experience with Firefox is hurt? 

Just read the comments here. There are many examples here.


> Of course you force.

If we were forcing, then obviously there would be no sites with any problems any
more. Since you are still arguing, we're clearly not forcing.


> And: Your interpretation of the Standards is just that. Your interpretation.

Yup.


> WONTFIX means you're not listening and you do ignore us

There are two groups of vocal users here -- some, including you, are in favour
of changing Mozilla's behaviour; others, including me, are against.

We obviously can't implement both, so automatically, one group is going to be
ignored. The Mozilla drivers (of which I am _not_ a member) agree with the group
that says this is a WONTFIX. They listened to both sides, and made a decision.
Just because they don't agree with you does not mean they aren't listening.


> Just read the comments here. There are many examples here.

The only site I've recently seen mentioned is my.ebay.com, on which I can't see
a problem that would cause users to not use Firefox.
>If we were forcing, then obviously there would be no sites with any problems 
>any more. Since you are still arguing, we're clearly not forcing.

Could it be that you _slightly_ overestimate Mozilla powers and it's impact on
the market?

>We obviously can't implement both, so automatically, one group is going to be

Of course you can implement both, and you know that. Implement both behaviours
and implement a pref so _users_ can have a say and make an informed _decision_.
I could personally even live with it if you make this pref per default Standards
compliant. If we could only choose and not be dictated.
There already is a pref, it's an extension, and has been mentioned several times
in this bug. Firefox's model is to not have prefs except where absolutely
necessary, and to let users customise their product with extensions.

This bug is about the default behaviour, not about a pref.
> If we could only choose and not be dictated.

You can.  The extension cited above:

http://piro.sakura.ne.jp/xul/_popupalt.html.en#download

worked perfectly (and almost instantly) for me.  I now get tooltips in Mozilla
and am a happy camper.  Personally I don't find the WONTFIX arguments
convincing, but there is a perfectly good alternative.  You can perhaps argue
that this is not going to be evident to most users, and so will hamper the
adoption of Firefox, but you do have the option of fixing Mozilla to work the
way you want.
>There already is a pref, it's an extension

sic!

>This bug is about the default behaviour, not about a pref.

If there would be a pref, and _not_ an extension, you would mark this bug not
WONTFIX but INVALID.

I know that an extension exists. I do not post comments here because I cannot
get my Mozilla to work. I post comments here because I find the attitude of the
Mozilla driver team at some points questionable, and quite endangering a
possible success in the market place.

As a part-time company owner I install Mozilla in most of my customers' systems.
And they complain about some things, tooltips being one of them. They only
accept this because of IE's security problems forces them to accept it. And no,
they don't want to install extensions, they only want offical code with official
support like Mozilla core code.

At work I have to use IE, because company policy demands 100 percent compliance
with the standard. And with that they mean the product with the overwhelming
market share ("industry standard").
(In reply to comment #549)
> We obviously can't implement both, so automatically, one group is going to be
> ignored. 

No. 
You _CAN_ implement it optionally to satisfy both user groups. But you deny to
make it even optional. It seems you are woodheads. 550 comments, 30+ votes, and
you still stuck with your weak opinion...

WAKE UP! Your Mozilla browser breaks millions of websites, which was based on
ALT texts so visitors are missing the tooltips. Those websites can NOT be viewed
correctly with Mozilla! Don't even dream that the rest of 80%-90% browsers users
will switch to Mozilla until this BUG is not fixed!!! 

Mozilla breaks the most known websites (also some known ones from your TOP 100
list), which websites are NOT displayed correctly under Mozilla, because Mozilla
doesn't display necessary ALT text as tooltip. Users are MISSING tooltips! These
websites WAS designed to have the ALT text displayed as tooltip!!!

So you can stick to your opinion, you can try to force the developers to use
TITLE instead ALT, but you can NOT force browser users to change from IE to
Mozilla, until your browser doesn't display a historical browser features, like
the ALT text as tooltip!

And you can not suggest for every 1000 million of users, for each one
separately, to install the popupalt (what the hell is that? says an average
user) extension to make a historical feature working...

Please read my earlier comments and my arguments:
Comment #160, Comment #162, Comment #164, Comment #172, Comment #174, Comment
#178, Comment #182, Comment #184, Comment #190, Comment #227, Comment #232,
Comment #246, Comment #249, Comment #259, Comment #263, Comment #288, Comment
#293, Comment #321, Comment #325, Comment #331, Comment #353, Comment #414,
Comment #471, Comment #474, Comment #476, Comment #477, Comment #481


Mozilla should not break the traditions, but better should support it!!!


Dream, a little dream, Ian and the leading Mozilla developers...

Listen to Oliver Kluge, what the companies says about ("industry standard"):
they mean the product with the overwhelming market share IS industry standard.
Unfortunately it is IE. I don't like it, but this is the truth. And most
websites are developed for industry standard IE browser, which owns the 80%-90%
of the market. 
Ian & leading Mozilla developers: fit to the market, fit to your users!

Make ALT tooltip feature at least optional to satisfy both user groups and every
needs.
Um, before you have a heart-attack, reality check: we're talking about tooltips
here. Any page that "breaks" when you can't view tooltips is already so broken
that it's beyond help. This is the main reason I just don't understand what the
fuss is about. Tooltips aren't even seen by most users, they only appear when
you hover over something and wait for a bit. Let's keep some perspective here.
(In reply to comment #555)
> Any page that "breaks" when you can't view tooltips is already so broken
> that it's beyond help.

You really don't understand. Tooltips are part of the feature of a website.
Most websites do actively use tooltips to inform users of several informations,
help infos, etc.
Tooltips was always important in user interfaces, including Windows OS, Windows
applications, Browsers, and even Linux GUI & applications.

So don't talk about tooltips, like talking about something, that it is not
important. That's false.

Users (you know those people, to whom basically you should develop usable
software) do NEED tooltips!!!
So if a website developed a tooltip with the aim to show tooltips for the users,
it should be displayed. No matter what the standards say... And the standards
doesn't say you are not allowed to show the ALT text as tooltip.

So serve the users, and fit their needs. 
Users need tooltips from both ALT and TITLE tags (at least optionally in quirks
mode as suggested)!
(In reply to comment #546)
> These days, web sites are no longer "written" by the Web site developers
> or publishers. 
<snip>
> Today, HTML pages are generated fully automatically by software. No Web
> developer has his or her hands on the code anymore. 

Err? Speak for yourself. I, and I dare say that the same goes for the vast
majority of professional web developers who follow modern semantically
meaningful design techniques (an ever increasing percentage), write more pure
HTML than ever, in pute text editing tools which don't even _have_ a "wysiwyg" mode.

Additionally, as mentioned several hundred comments ago, I was someone who first
went to actualy read the W3C specifications exactly because of Mozilla not
showing alt as tooltip.

- Just a comment from the mostly silent majority agreeing with Hixie, with an
apology to anyone cc-ed who isn't yet resigned to all the spam.
(In reply to comment #545)
> Our mission _does_ include making Web developers write better code:
>    http://www.mozilla.org/about/
> 
> Showing alt attributes in tooltips would encourage authors to only use alt
> attributes for tooltips, which is bad because when the tooltip and the alternate
> text should be different (often), then it reduces the quality of the alternate
> text, reducing the experience for people who don't have images.

Ian, I don't buy your simplistic and idealistic view of the applicability of alt
tooltips. Under the terms of the ADA (Americans with Disabilities Act), users
should no more be denied alt tool tips than they should be denied images. Please
think about this carefully. You are unwittingly discriminating against tens if
not hundreds of thousands of users who have disabilities. Disabled people come
in all shades. The population of users is not just made up of fully sighted
20-20 vision ("normal") people and blind people who must use a text-to-voice or
text-to-Braille reader. Therefore I demand that all users of all shapes and
sizes and degrees of disability should be able to use Mozilla Firefox to
experience a website from whatever perspective gives them the best and most
complete experience.  This often entails using images as well as alt (and/or
title) tooltips to the degree that they can be seen by such (sight
disabvantaged) users. By breaking the alt tooltips on websites when browsed with
images, you and the Mozilla elite are _worsening_ the browsing experience for
the whole population of users (which includes all levels of disability), not
improving it. Consequently, your Mozilla Firefox browser is the one with the
reputation for being difficult to use for people with disabilities, not IE6.

I have a friend who does not see images the way that I and presumably you do,
but still gets value out of them, and yet can read plain text against a uniform
background quite well, provided the Windows color scheme is suitable. He needs
_both_ the pictures and the tooltips, and it doesn't really matter if the
tooltips are alt or title, as long as there is one. He’s not alone in this;
there are countless others with similar or worse such problems. This strongly
suggests that Mozilla should be changed to use a preference to give either alt
or title tooltip display priority: And if the preferred one is missing, the
other will be shown.

So, Ian et al., if you really believe in the ADA and the honest intent of the
W3C specs (to improve the browsing for people with all shades of disabilities
(which probably includes everyone over the age of 35 ;-), you'll start wanting
to change WONTFIX into will fix with a high priority.

Please don’t turn this into a face-saving “won’t fix” exercise, but just
implement in the broadest way possible the W3C’s real intention, that of making
the maximum amount of the www available to the most people. And that intention
leads directly to the solution that you are being hammered on, that of allowing
alt tooltips to show if there’s no title tag. It does _not_ lead to WONTFIX
which is just so wrong in light of the ADA that it’s no longer funny.

BTW, the extension cited earlier,
http://piro.sakura.ne.jp/xul/_popupalt.html.en#download
is absolutely not a solution for most of the population; it’s just too danged
difficult to install and even to understand how to install it or whether it is
even safe to install it at all. Most users don’t want to get involved in any
technical details. Try reading the installation instructions from the
non-technical perspective. Most people will say something like, “You want me to
do what?”
 
I don't think I need to belabor my points in this response any further, so I'll
just shutup and invite comments from all and sundry!
Hixie wrotein comment #551:

> Firefox's model is to not have prefs except where absolutely
> necessary, and to let users customise their product with extensions.

This is actually a good argument to make it a pref at least in Seamonkey (the
suite) as there model is clearly different here. 

Yesterday, I put forward an analogy to the recent document.all decision. I'll
add another example where Mozilla went for a microsoftism that had much less to
do with standards than atl text tooltips (as it isn't even mentioned in any
standard). One word: <marquee>

One final note. If we implemented alt text tooltips today (even as a non-default
hidden pref), I am 100% sure that Asa would list it as a success in 1.8b6
Release Notes in the "Under the hood" section. So why shoot in one's own feet by
not implementing it?
> You really don't understand. Tooltips are part of the feature of a website.
> Most websites do actively use tooltips to inform users of several 
> informations, help infos, etc.

That's clueless if the info is in the alt attribute. On the Mac, there is no
Windows IE and browsers don't show the alt attribute as a tooltip. Even the Mac
version of Netscape 4.x didn't show the alt attribute as a tooltip.

Also, if an icon is designed in such a way that a person with normal cognitive
abilities cannot understand the meaning in the cultural context without textual
aid, the icon is badly designed or the thing should be represented as text and
not as an icon in the first place. (Yes, a large part of MS Office toolbar items
are easier to understand and scan as menu items.)

There is the special case that some users might see the image but still have
trouble with graphical symbols when it is not a problem for the general
population. However, this case is more rare than the case where the user sees
the image and does not need to see the alternative text if it is truly
alternative and the case that the user does not see the image but really needs
to see a good alternative text. (The extension already addresses the case.)

See http://www.mozilla.org/docs/web-developer/faq.html#alttooltip
Displaying the alt text as a tooltip degrages the quality of alt text.
Sander, can you prove this claim
>- Just a comment from the mostly silent majority agreeing with Hixie, with an
>apology to anyone cc-ed who isn't yet resigned to all the spam.

What makes you believe that the vast majority is agreeing with Hixie? From my
own business perspectiv, I do not know one single customer of mine who does not
complain about several incompatibilities of Mozilla, tooltips being one of them.

At my workplace, a large company with > 3000 desktops, nothing with less than
100 percent compatibility with the industry standard will ever have a chance of
getting rolled out.

>Any page that "breaks" when you can't view tooltips is already so broken
>that it's beyond help. This is the main reason I just don't understand what the

Sorry, no. Hixie, you are a highly-skilled professional. You have a _vastly_
different approach to using a GUI than practically 90 percent of all other
users. At least I suppose you have the same approach that I have and practically
all technically and scientifically trained people that I know. I apologize if
this assumption should be wrong.

We understand the concept of "GUI" in a very different way, because we see a GUI
as an enabler that saves us from typing commands. We all have seen billions of
logos and icons, so we understand the meaning of a symbol much faster than
ordinary users. I do not want to say ordinary users are dumb; it's just that
their approach is different. We click on the right icon the very instant we want
to have something done, and secretly we feel that we would be faster with a
keyboard and keyboard shortcut commands.

I have been in the industry for almost two decades now. Have you ever watched
how secretaries used to organize their computer work then and now?

In the good old WordStar times they kept a small hand-written note ready that
readily listed the top-twenty Ctrl-K or dot commands (remember Ctrl-K-B,
Ctrl-K-E ?). These days some of them have notes with tiny little drawings on
them, depicting the symbols they have to click on.

Tooltips are simply a technical implementation of the note sheets, as well as
their bigger cousins, bubble help dialogs. So if you claim that if the GUI of a
website is "beyond help" if uses tooltips, then you claim that the very concept
of _GUI itself_ is broken.

Talk to people who work on Service Desks. Software that incorporates bubble help
gets less support calls! Realize that for ordinary people many many concepts of
_GUI itself_ really _are_ broken. One example I have heard from more than one
customer: "Why do I have to click on "Start" when I want to turn off my
computer?". We would not think of this being a _problem_, we know the necessary
dialog is behind that button, but for normal users _it is_ ! As trained people
we have to get out of the ivory tower and try to think the way our users think,
and it's very different! Walk in their shoes...

>fuss is about. Tooltips aren't even seen by most users, they only appear when
>you hover over something and wait for a bit. Let's keep some perspective here.

Of course tooltips are seen by _all_ users, because normal people don't just
"point and shoot" with the mouse, they are much much slower than you and I. Have
you ever been or worked in a GUI laboratory? You would be amazed at how slow
some people use the mouse, they barely touch it.

But of course, I'll have to correct myself. Not _all_ users see tooltips. All
users of IE, I have to add. But that's the vast majority anyhow.
As another user who mostly stays silent on the subject:

No I don't agree with Hixie, but as with most of the people who don't I've
completely resigned myself that this situation is hopeless, as many of the
outstanding mozilla bugs are. They won't be fixed because of stubourness and
evangelism about certain interpretations of the standards with no concern to
real life usability. 

Just give it up, trying to put forward any views towards the mozilla project is
in it's entirerity a waste of everyones time. Mozilla is not a user lead
project, it is a fantasy lead project with no basis in the real world, and as
long as it is controlled by the few stubourn people who live in fantasy land, it
will continue to be so.
(In reply to comment #560)
> See http://www.mozilla.org/docs/web-developer/faq.html#alttooltip
> Displaying the alt text as a tooltip degrages the quality of alt text.

Not displaying alt text all, results really BAD tooltip quality, since it
doesn't display tooltip at all!!!
This is getting borring, how about we just have a pref for this off by default
and end all the arguing. *Hides*, of at least take this discusuion over to bug
74241 because this is going know where.
Summary: alt text is not displayed as a tooltip over <img> (image) → (Warning 56k) Alt text is not displayed as a tooltip over <img> (image)
Ah the Alt Text religious war.

First, I agree alt text should not be shown as a tooltip in strict mode. That's
the point of strict mode.

As for alt text not tooltipping in quirks mode, the best argument made by the
"no" camp is that the user isn't missing much, and can download a plugin if
they're so inclined. Yet it has been mentioned repeatedly that document.all was
implemented - something that arguably causes the user to miss about as much.

So really, the argument here is that alt text isn't a big deal, and that's why
it's not implemented. The campaign is presumably to cause IE to follow suit, and
to see websites not abuse alt. But precisely because alt isn't a big deal, IE is
unlikely to see this ever fixed. And while websites abuse alt, there are many
pages that are long since forgotten by the author - they will never change - yet
contain a great deal of good content, even in alt text. The average user is
supposed to be aware of the religious stance of the Mozilla team, aware of the
alt text plugin, go find it, and install it just to get this missing content?
Instead of using IE, already sitting on their machine?

Just trying to bring some reality to this argument.

It makes perfect sense to have alt as tooltip only in quirks mode, as mentioned
in comment 13, 14, 51, 124, 160, 172, and so on. Make it a pref the user can
disable if they hate it. Clearly at this many comments this issue has been
handled in an extreme way - take a more middle of the road position like quirks
mode + pref, and be done with it.
reply to https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c545 From Ian
'Hixie' Hickson
"Now tell me this: Why are you campaigning to have Mozilla break their code
instead of campaigning for Microsoft to fix theirs?"

I have two good arguments:-) 1) I don't want to use IE. 2) IE does not have this
problem. 

The right question would be "Why don't you ask the authors of the sides which
use alt= for tooltip purpose?"

https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c549 From Ian 'Hixie' Hickson
"The only site I've recently seen mentioned is my.ebay.com, on which I can't see
a problem that would cause users to not use Firefox."

You can only see it if you have sold or buyed stuff. There are many icons which
tell you if the item was shipped, payed. if you have got feedback, if you have
given feedback etc.

There are so many examples. e.g.
http://forums.civfanatics.com/forumdisplay.php?s=&forumid=23

Do you know that the following Icon means "Poll"?
<img src="http://forums.civfanatics.com/images/misc/poll_posticon.gif" alt="Poll">

No side is completely broken. It's just missing comfort at many different
places. Oliver Kluge describes in detail why this is a show stopper for a large
amount of usere here https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c561

reply to https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c552 From Mike Christie
"The extension cited above worked perfectly"
But it comes only from a Japanese side with some Englisch texts. And it does not
handle title="" correct. When it could be found on
https://addons.update.mozilla.org/extensions/ and the title="" issue would be
fixed, then it would be an alternative for many of us. But as Oliver Kluge
mentioned above not for all of us.


Overall nobody explained yet why the bahaviour [a] should not be adopted:
                                      FF1.0  IE6  Lynx  NS7.1  FP2K*
   img with alt="a",    no title tag    -    [a]   a     -      a    

More details in https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c543 and
https://bugzilla.mozilla.org/show_bug.cgi?id=25537#c544

There is not a single example how this would hurt anybody. Neither for existing
nor for future pages. Only diffuse arguments like nobody would use alt=
correctly anymore etc. But why?

It was already mentioned that there are not only blind people and people with
good vision but also people with redused vision. A colleague of mine sitting in
the next room is a good example. She uses a 21" screen with a 800x600
resolution. I talked to her and for her it is a big problem not to have tooltips. 

Unless there is an argument against it other than religion I don't agree that it
should be a pref option. It should be the standard behaviour. But when it is not
possible to get an consense a pref option would be better than nothing.

> There are so many examples. e.g.
> http://forums.civfanatics.com/forumdisplay.php?s=&forumid=23
> Do you know that the following Icon means "Poll"?
> <img src="http://forums.civfanatics.com/images/misc/poll_posticon.gif" 
> alt="Poll">

You mean the one that says "Poll" right next to it?


> No side is completely broken.

In that case quirks mode is inappropriate and document.all is a false analogy.
In the document.all case, and for all the quirks, there were major sites that
were completely broken.


> Overall nobody explained yet why the bahaviour [a] should not be adopted:
>                                       FF1.0  IE6  Lynx  NS7.1  FP2K*
>    img with alt="a",    no title tag    -    [a]   a     -      a    

It has been explained many times. If we show a tooltip here, we are encouraging
authors to treat "alt" as a tooltip attribute, and when it is used as a tooltip
attribute instead of its correct purpose (alternate text conveying the same
content as the image, as opposed to additional text that goes _with_ the
information conveyed by the image) people who need real alt text suffer.

In any case, it is inappropriate (there is no reason for the "alt" to be shown
in a tooltip _other_ than the fact that authors have misunderstood what "alt" is
for). The only argument would be for making this a quirk, and as already
mentioned, this doesn't pass the bar for being made into a quirk (nobody has yet
shown an important page -- or in fact any page -- that this breaks enough).


> It was already mentioned that there are not only blind people and people with
> good vision but also people with redused vision. A colleague of mine sitting 
> in the next room is a good example. She uses a 21" screen with a 800x600
> resolution. I talked to her and for her it is a big problem not to have 
> tooltips.

And I spoke to someone earlier today who mentioned that he found tooltips really
annoying.

The disabled user case is a bad example, because in the case of the disabled
user, what they want is the alternate text, and not the title or caption.
However, the people asking for this bug to be fixed are asking for the title or
caption to be shown, even when it is incorrectly put in the alt attribute, and
are not asking for the alternate text to be shown (as witnessed by the fact that
you are all asking for title to override alt when both are present).

For the small minority of people who have a genuine need, there are
accessibility tools and extensions.


> But when it is not possible to get an consense a pref option would be better 
> than nothing.

Firefox is not driven by consensus. It is driven by a dictatorship, like most
successful Free software products (and for that matter, most successful
commercial products as well). Having a pref for this would be _even worse_ than
having tooltips appear for alt attributes in the first place.
"> No side is completely broken.

In that case quirks mode is inappropriate and document.all is a false analogy.
In the document.all case, and for all the quirks, there were major sites that
were completely broken."
I never made this analogy and I agree that it's something diffrent.
"document.all" is about IE corrupting the standard. This discussion is about
what the standard should be.

"It has been explained many times. If we show a tooltip here, we are encouraging
authors to treat "alt" as a tooltip attribute, and when it is used as a tooltip
attribute instead of its correct purpose (alternate text conveying the same
content as the image, as opposed to additional text that goes _with_ the
information conveyed by the image) people who need real alt text suffer."

Maybe I'm just to narrow minded but I still don't understand it. To show place
holders like alt="-------" might be annoying. But this seems to me a misusage of
alt= 

Can you give an example, please? What would an author put in alt= what would
annoy when it is shown as a tooltip? Wouldn't it be it a solution when title=
overrides alt= ? 

"And I spoke to someone earlier today who mentioned that he found tooltips
really annoying."
That's really hard facts. I really feel sympathy for this poor guy with his
horrible fate. In fact many people still prefere command line tools. We really
should get rif of all this GUI stuff :-) 

"The disabled user case is a bad example, because in the case of the disabled
user, what they want is the alternate text, and not the title or caption.
However, the people asking for this bug to be fixed are asking for the title or
caption to be shown, even when it is incorrectly put in the alt attribute, and
are not asking for the alternate text to be shown (as witnessed by the fact that
you are all asking for title to override alt when both are present)."
title= is meant to get tool tips. Why should someone want the alt= text when
title= exists. alt= is the replacement when no pictures are show. title= is a
more detailed explanation of the picture. Why should this not fit even better
than alt=?

"For the small minority of people who have a genuine need, there are
accessibility tools and extensions."
It's a far spread misunderstanding that the world exists of a majority of people
with good vision and a minority of blind people. All others can be ignored. I'm
sorry but this is ignorant. As far I know there are more people with bad vision
than blind people. The altruistic argument to fight for a bright future of the
blind people is not realistic. It does not match the real world.

Yes, for me there is no side yet which is completely broken. It's annoying on
very many sides, but there is always some kind of workaround. I can install the
extension from the Japanese side and live with it. But as mentioned before
tooltips are very important for the usability for many sides and it is a big
advantage of IE that they are shown. It's not a minor issue for many users. It
does make a difference!

"Firefox is not driven by consensus."
That's obviously true :-; But I want to thank you that you still argue with us.
I know that a consensus is not always possible. But usually I don't want to give
up to find a consensus until I understood the arguments of both sides.

"Having a pref for this would be _even worse_ than having tooltips appear for
alt attributes in the first place."
Yes I agree. But it would still be better than the current situation.
(In reply to comment #568)
568> Maybe I'm just to narrow minded but I still don't understand it. To show
568> place holders like alt="-------" might be annoying. But this seems to me
568> a misusage of alt= 

Then you've lost sight of what alt= is for: a textual replacement for an image
when it cannot be displayed.

alt="------" is good alt text for a graphical horizontal rule.
alt="*" is good alt text for a graphical list bullet.
alt="[Send]" is good alt text for a graphical button reading "Send".

All of those are good alt text. Good alt text generally makes redundant and
useless tooltips.
*** Bug 282767 has been marked as a duplicate of this bug. ***
(In reply to comment #569)
> alt="------" is good alt text for a graphical horizontal rule.
> alt="*" is good alt text for a graphical list bullet.
Blind people do not need graphical lines and bullets. This looks more like an
optimization for LYNX users. Anyway with title="" the tooptip could easily be
suppresed standard conform. We are asked to give examples where tooltips are
missing. There are a lot. Do you have an example for a page where these kind of
tooltips do break a site?
> alt="[Send]" is good alt text for a graphical button reading "Send".
Most send buttons can be identified easily. That's right. But many other buttons
are definitely not self explaining. Sure there is normally a legend somewhere.
But unfortunately usually not visible when I need the information. Why does the
tooptip "Send" hurt?

In a nutshell we have a very academic discussion instead of a pragmatic solution.

FF is ment to stop the monopoly of IE in the net and give the usere a choice.

When I look through this thread or this one
https://bugzilla.mozilla.org/show_bug.cgi?id=267285 about the "Print..." option
in the context menue i fear that when IE7 comes you will have a dramatic loss in
market share over the time. And when IE is back on 99% you there will not be a
choice anymore.

*** Bug 283502 has been marked as a duplicate of this bug. ***
(In reply to comment #571)
> Blind people do not need graphical lines and bullets.

So you should specify textual replacements.

> This looks more like an optimization for LYNX users.

For braille monitors, teletypes, dumb terminals, &c.

> Anyway with title="" the tooptip could easily be suppresed standard conform.

With alt="..." title="...", replacement text can easily be made into a
standards-conforming tooltip.

It's more efficient to use alt="..." title="..." in those rare instances when
replacement text is a desirable tooltip, than alt="..." title="" in the far more
common cases where replacement text is a useless tooltip. See comment #473.

> Why does the tooptip "Send" hurt?

This bug has many responses to that question. Comment #427 is one of mine.

> i fear that when IE7 comes you will have a dramatic loss in
> market share over the time. And when IE is back on 99% you there will not be a
> choice anymore.

I think Mozilla would gain more market share by being better than IE than by
emulating its design flaws.

Moreover, Internet Explorer has never had 99% market share, and I believe it
never will. IE7 would have to be considerably better than Firefox to make me
want to buy Longhorn to get it.
*** Bug 289495 has been marked as a duplicate of this bug. ***
*** Bug 291241 has been marked as a duplicate of this bug. ***
*** Bug 294028 has been marked as a duplicate of this bug. ***
*** Bug 294417 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Another altenative for those who want to display replacement text as tooltips:

Anthony Lieuallen has written a script for the Greasemonkey extension which copy
replacement text to title attributes (if a title attribute does not already exist).

http://www.arantius.com/article/arantius/alt+tooltips+for+firefox/
*** Bug 299172 has been marked as a duplicate of this bug. ***
(In reply to comment #569)
> alt="------" is good alt text for a graphical horizontal rule.
> alt="*" is good alt text for a graphical list bullet.
> alt="[Send]" is good alt text for a graphical button reading "Send".
> 
> All of those are good alt text. Good alt text generally makes redundant and
> useless tooltips.

Wait a second, here. Whilst I agree that alt-text should _describe_ the image in
a textual fashion, surely it must be better to use alt="[Horizontal Rule]" or
something like that, as opposed to a string of hyphens (of arbitrary length)
that, I imagine, may very well be considered to be disadvantageous and annoying
to users of screen readers and other output devices, when the same character is
announced repeatedly?

It occurs to me that I'd much rather hear _meaningful words_ conveyed about an
element; or, when such a description of a _visual display enhancement_ would
actually have an adverse effect in terms of cluttering up the User Agent output,
when it clearly isn't necessary, I would prefer it if the alt attribute was left
empty. That seems like a more sensible approach to me, as good markup techniques
would of course allow the software to decide for itself where to pause -- such
as between paragraphs or other block-level elements, for example. (Although if
it is necessary to at least include a <hr> tag to separate content for some
reason, it's surely more accessible to do so in this case? A CSS border would be
completely invisible to most readers, I'd imagine; of course, it should stay
that way.)

I have tried at least one audio screen reader, for the sake of it, and even
during the brief period of time that I tried it at the local library, it wasn't
very good really. Not yet anyway, with the former -- and current -- minefields
of browser "tag sludge" (for wont of a more accurate description than "soup")...
It seems to be slowly picking up the pace though.

I've bloody rambled quite a bit now, so I'll just finish by mentioning how
laughable I think the W3C Recommendation for a lot of those "Audio CSS" rules
is... I mean, what the hell's going on when a poor user, who may be perfectly
happy with his own customised text-to-speech program's configuration, may one
day suddenly be confronted with an absurd style rule that can change the voice
character settings, volume, etc??? I know I'd hate for that to happen; even if
there was an option somewhere to prevent would should be out of the question
entirely. It sounds like those mostly silly "MS Agents" of all things -- and
speaking of Microsoft, isn't it just a tad hypocritical of them to criticise the
(albeit also stupid) proprietary scrollbar appearance "extensions" in IE, for
example?

Oops, I have digressed a bit, lol... When I code myself from now on, though --
which isn't a lot -- I've decided to try and stick with this strategy, which
seems just what the "Oh-So-Precious" Standards ordered:

1) If there's an image, it'll be something like alt="Image: Graph showing
website usage statistics" title="Well, as you can see here, January didn't go
down well, did it?"; and then of course, supporting text in the relevant <p>. It
seems like nonsense to repeat the alt-text in both attributes -- even if it was
"valid" alternative text, surely it's not too difficult to use title from now
on, at least, when you want to describe it indirectly, or comment on it?

I know all those "bad, bad" sites of the past may be left without their tooltips
for a long time -- forever even, if they're still around in a few years -- but
what is the true level of "sacrifice" in relation to their content? It can't be
_too_ bad an outcome -- I dread to think of a scenario where the text they
"regurgitated" to the user was never once presented formally on-screen.

2) For a submit button, what's the point of repeating "[Send]" in the alt-text,
if it's just a plain old UI element with the text already there, and an obvious
assertation that it's a button? I'd only use alt if it was strictly necessary
here -- and I doubt that I'll ever be tempted to bother with those bloomin'
image buttons, which must surely be resented by compliancy conformists?

3) The use of <hr> tags sparingly, if I feel that there needs to be further
division than achieved by paragraphing alone; some sense of separation needs to
be preserved in the "plain" mode when CSS is disabled or not in use.

And I'll leave you now, because this is far too long and diverse. I hope IE7
doesn't have too much of a negative impact upon the Firefox ball that's well and
truly been set in motion! They've got a _lot_ to even think about redeeming
themselves for, regarding gaping security flaws that shouldn't've been there in
the first place (lol, thank whatever deities there may or may not be in the
universe for Open Source projects, to paraphrase the words of many), silly
annoying quirks even in "Strict" mode... And so on. As I said, though, time for
me to sleep! :)
(Addition to comment #580)

I've just realised that the example usage of such a title attribute for an image
tag may not, strictly-speaking, be "semantically correct" -- I mean, shouldn't a
so-called title be just that, a title? Ach, the distinctions between the two are
so contrived in places, surely it'd be better for everyone's sake if people just
realised the importance of a good, legible description for certain visual
elements; and there had been a single, clear attribute defined from the start?

It just seems to me that, often, the two can be successfully and meaningfully
incorporated into a single "string" -- a lot of the time, a good title is just
as good, if not better, for someone who can't see the image; as long as it's
established with that in mind, right? For instance, why would alt="Image: A
basket of fruit" be necessary if essentially the same thing was echoed in the
title, regardless of the image-load status or visibility? Unless it's something
to do with how the basic alt-text is displayed within the placeholder
immediately, instead of the user having to invoke it via direct response i.e.
"mouseover"? I guess, that way, it deals with both graphical and non-graphical
browsers...

Having to split up what naturally forms "as one" in my mind is awkward to do,
though. Then again, sometimes it is obvious. And at least you can leave the
alt-text blank, of course, and omit the title, if it's really not necessary to
expand upon something.

PS: And is it really necessary to use alt="[*]" for bulleted lists? It sounds
pretty pathetic to me, if a reader can't parse an obvious <li> tag... Although,
I'm sure I've heard screen readers say stuff like, "List item: Example 1; List
item: Example 2" etc. Seems pretty simple to me...
*** Bug 301023 has been marked as a duplicate of this bug. ***
It is all very well for those who are employed to write HTML to insist that
Firefox will not display ALT text in tooltips and suggest that everyone should
change their existing code. I don't get paid for developing my website and I do
have a life to lead. The fact is that millions of websites use ALT and expect a
tooltip to appear as a result. If Mozilla wants to remain on the sidelines, of
interest only to nerds, refusing to acknowledge that fact is the way to go about it.

Maybe the way forward, at least here in the UK, is to refer the matter to our
Disability Rights Commission with a view to a prosecution. As I interpret it,
this refusal to activate the ALT facility is in breach of the UK's Disability
Discrimination Act 1995 Part III, which came into force on 1 October 2004. This
places new duties on service providers where physical features make access to
their services impossible or unreasonably difficult for disabled people. When a
very simple change could rectify the matter and other browsers have been able to
implement the facility without difficulty a court is almost certain to convict
under the Act. 

The court will, naturally, take into account the wide usage of the ALT feature
and, regardless of W3C, is likely to regard Mozilla's refusal to acknowledge
this de facto standard as perverse. 

Such a conviction would, of course, make it illegal in the UK to provide
Firefox, as it stands, for use by another person. It also means that anyone who
uses ALT on their website should recommend UK users not to use Firefox to browse
the site to protect themselves against action under the DDA.

For my part I shall also recommend that since Firefox is incapable of handling
the facilities included in my HTML all users of my site should use IE if they
want to get maximum value from it. Which is a great pity!
Wondering if someone who knows how to write a Firefox extension could implement
a short bugfix to provide tooltip display of alt text.
(In reply to comment #583)
583> The fact is that millions of websites use ALT and expect a
583> tooltip to appear as a result.

An unsubstantiated claim you just made up is not a fact.

583> As I interpret it, this refusal to activate the ALT facility is in breach
583> of the UK's Disability Discrimination Act 1995 Part III, which came into
583> force on 1 October 2004. This places new duties on service providers where
583> physical features make access to their services impossible or unreasonably
583> difficult for disabled people.

Your interpretation does not make sense.

* The alt attribute is active; replacement texts work just like they should.
When an image cannot be loaded or images are disabled, replacement text is
displayed.

* Firefox is a Web browser, not a service provider.

A website that is unnavigable without popping up replacement text does make
access to their services unreasonably difficult for disabled people, but
browsers have no duty to repair their brokenness.

583> The court will, naturally, take into account the wide usage of the ALT
583> feature and, regardless of W3C, is likely to regard Mozilla's refusal
583> to acknowledge this de facto standard as perverse.

Bosh.

This 'feature' is a mistake, which every major browser except IE/Win
has corrected -- current versions of IE/Mac, Firefox, Mozilla, Netscape, Opera,
Konqueror, Safari, and iCab do not pop up replacement text.

583> Such a conviction would, of course, make it illegal in the UK to provide
583> Firefox, as it stands, for use by another person.

Such a conviction would, of course, be idiotic. And unrealistic.

583> For my part I shall also recommend that since Firefox is incapable of
583> handling the facilities included in my HTML all users of my site should
583> use IE if they want to get maximum value from it. Which is a great pity!

Better you should use HTML that works in any browser, but it's your choice. Be
sure you specifically recommend IE *for Windows*, since like most browsers,
IE/Mac doesn't pop up replacement text either.
>This 'feature' is a mistake, which every major browser except IE/Win
>has corrected -- current versions of IE/Mac, Firefox, Mozilla, Netscape, Opera,
>Konqueror, Safari, and iCab do not pop up replacement text.

This statement is highly misleading. It sounds as if only a minority of
installed browsers would display alt tooltips. That would be the opposite of
reality. In fact, it's just the other way round: the overwhelming majority of
installed browsers display alt tooltips.
(In reply to comment #586)
And "majority of installed browsers" is just slightly more than "the majority
browser" (or rather, "releases of the majority browser for the majority
operating system").

alt="" replacement text pops up tooltips in IE for Windows and some obsolete
browsers (Netscape 4 and below, Mosaic, HotJava).

title="" advisory text pops up tooltips in IE for both Windows and MacOS,
Netscape 6 and up, Firefox, Mozilla, Opera, Safari, Konqueror, iCab, and others.

If you want tooltips on your pages, use the real "de facto standard": title="".
Correction: Mosaic does not pop up replacement text tooltips either.
>And "majority of installed browsers" is just slightly more than "the majority
>browser" (or rather, "releases of the majority browser for the majority
>operating system").

"slightly" is a funny term for the fact that the difference means "90% market
share". It always amazes to see such plays on words that hide facts that aren't
welcomed.

And no, it's not just "the majority browser".

AOL Time Warner has decided to add the Trident engine to go along with Gecko in
the current Netscape, so they went half a step away from Gecko. And guess why?
Because it gives users the experience they want. Gecko is used only for sites
that the browser finds untrustworthy for security assumptions.

Netscape's slogal is (quote) "Finally a Browser that Fits Every Site."

Obviously Netscape thinks that Gecko/Mozilla is _not_ fit for every site.

I guess you won't call the current Netscape "obsolete", looking at the number of
customers AOL has?

>If you want tooltips on your pages, use the real "de facto standard": >title="".

Again, the point was completely missed. It's not about me (or our) pages. It's
about the pages that are there and give 90% of all users a certain experience.
One that Mozilla (or rather Gecko) doesn't. 

And alt tooltips are a de facto standard, too. Based on a sloppy standards
definition, admittedly. But they are there. And they will not go away and you
can't tell people to surf elsewhere. 






(In reply to comment #589)
588> And "majority of installed browsers" is just slightly more than "the
588> majority browser" (or rather, "releases of the majority browser for the
588> majority operating system").

589> "slightly" is a funny term for the fact that the difference means "90%
589> market share".

"Slightly more" here refers to the negligible difference of Netscape 4 and HotJava.

IE's marketshare has fallen to 85%, according to the most up-to-date figures
I've seen (www.e-janco.com/browser.htm). That 85% includes both Windows and
MacOS versions, but I expect Windows is most of it.

589> AOL Time Warner has decided to add the Trident engine to go along with
589> Gecko in the current Netscape, so they went half a step away from Gecko.

You have a point -- Netscape 8 now lets the user switch between Firefox and IE
rendering engines, and its behavior depends on its mode.

> Because it gives users the experience they want.

Because it gives users ActiveX.

> Gecko is used only for sites that the browser finds untrustworthy
> for security assumptions.

Wrong. Gecko is used by default, and also with untrustworthy sites. As
installed, it only risks using the Internet Explorer engine with a handful of
'trusted' sites like WindowsUpdate.com, Microsoft.com, MSN.com, AOL.com,
Netscape.com, Gmail.google.com, and ironically, Mozilla.org.

> Obviously Netscape thinks that Gecko/Mozilla is _not_ fit for every site.

From my point of view, some sites are not fit for every browser.

> Again, the point was completely missed. It's not about me (or our) pages. It's
> about the pages that are there and give 90% of all users a certain experience.

If your goal is for a page to produce the same 'experience' on every browser on
every operating system, then you miss the point of the Web. Also, <=85% now.

My point in #588: if you want users to experience tooltips, title="" is the
attribute to use.

> But they are there. And they will not go away and you
> can't tell people to surf elsewhere.

<layer> may never disappear completely from the Web. No one tells people not to
surf pages that rely on <layer>. They just find a page that doesn't work, and
likely move on to one which works in all browsers.
Obviously Netscape thinks that Gecko is not fit for the job, otherwise there
would be no necessity to add IE. They had two major releases relying totally on
Gecko. Now they moved backward and integrated Trident.

Integrating the IE (Trident) into that browser must have cost some money. A
company will most likely only spend that if it sees some return, and that means:
Customer demand.

>and likely move on to one which works in all browsers

In real world there is no such thing as a user who moves away from a website
that contains content that the user wants to experience, just because his
browser doesn't show this content to him.

The user will most likely move on to a browser who does the job. Just like
Netscape did, obviously by demand.

Netscape is listening, many Mozilla/Gecko developers aren't.

Apparently this has been done (comment 225) but it is not listed in the set of
Firefox extensions, so it will not get wide exposure.
https://addons.mozilla.org/extensions/?application=firefox

Recommended:  add it to the public list of extensions and maintain/improve as
appropriate.
*** Bug 304844 has been marked as a duplicate of this bug. ***
*** Bug 271900 has been marked as a duplicate of this bug. ***
*** Bug 310345 has been marked as a duplicate of this bug. ***
*** Bug 310744 has been marked as a duplicate of this bug. ***
*** Bug 312066 has been marked as a duplicate of this bug. ***
*** Bug 316374 has been marked as a duplicate of this bug. ***
*** Bug 322743 has been marked as a duplicate of this bug. ***
*** Bug 322743 has been marked as a duplicate of this bug. ***
*** Bug 332680 has been marked as a duplicate of this bug. ***
*** Bug 337455 has been marked as a duplicate of this bug. ***
*** Bug 337529 has been marked as a duplicate of this bug. ***
*** Bug 339851 has been marked as a duplicate of this bug. ***
*** Bug 343060 has been marked as a duplicate of this bug. ***
*** Bug 346705 has been marked as a duplicate of this bug. ***
*** Bug 358597 has been marked as a duplicate of this bug. ***
*** Bug 359378 has been marked as a duplicate of this bug. ***
I may be a few years too late for this ding dong, however I have a query with respect to Monzilla's moral crusade on this subject;

Not being particularly technically aware in regard to software programming and ethics and etiquette, I have read the 1st 350 odd posts and been educated.  I don't have the time to read the remaining 250 or so, but would like to know is Monzilla planning to stand alone in this fight against 'poor programming'?  Has there been any attempt at collaboration with the likes of IE in this respect?  This may sound a little daft, but let me give an example from my working experience.

I am by trade a barman.  Becoming more and more aware of legislation and good working practice, I realised that most colleagues in the trade will quite happily pour a fresh drink into a used glass.  This carries a very minor hygiene risk, and in my personal opinion is a poor working practice allowing compromising standards of service.  I went on my own moral crusade by refusing to follow the norm for a slightly greater good.  The result?  A lot of old fashioned baffoons decided they didn't like my approach, with a few stalwarts insisting that someone else served them.  I didn't make much headway, despite appreciation from some customers.  Later, I was promoted to manager, and had the ability to install my moral crusade as company policy, so all staff followed suit, and were educated as to why.  When everyone was working in the same direction, all of a sudden reputation was boosted, and there was commendation from most, as opposed to condemnation.  The moral of the story?  One man alone cannot change the world, but many working together can make an impact.  How the heck will the software programmers of the world change their ways when a nominal percentage of 10% of the world web surfing software people want them to?  Get IE to place influence too, maybe with (if they care) them saying 'in 2 years, we are dropping the ALT tooltips'.

After about 2 months of usage, I shall probably be discontinuing my use of Firefox as 90% of my web surfing is gaming, a vast majority of which is 1 game (itsagoal.com) of which a large proportion is reliant upon ALT tooltips and having to press SHIFT+R every time I would like to interpret a graphic into a readable figure is a sickener.  I find it a shame as otherwise I find the browser great bar this irritation, but am condemning myself back to IE for now for convenience.  I wonder how many others have done the same, thus 9/10 people still using IE?  IF Monzilla had for the past 5 years enabled ALT tooltips, then how much greater could their market share be?  Possibly enough to throw its weight around and be able to dictate how programmers should and shouldn't be writing their HTML?  I'm pretty sure if IE's market share decided they needed programmers to change their working practices, they would at the double as the vast majority of programmers would like to see their work accessible to as many as they can.  Monzilla's stance seems like a misplaced bullish approach with very little to back their stubborn stickling to the rules in the same manor of a Yorkshire terrier yapping at a man, who happens to have a big rottweiler to back him up.  If you really want to make a difference, then my personal opinion is your current approach is foolishly misguided, and detrimental to Monzilla's popularity and accessibility. 
612> I don't have the time to read the remaining 250 or so, but would
612> like to know is Monzilla planning to stand alone in this fight
612> against 'poor programming'?

If you think Mozilla is the one standing alone, you've got it backward. Mozilla stands with every other modern browser, including Netscape, Opera, Konqueror, Safari, iCab, and Internet Explorer -- for the Mac.

Internet Explorer for Windows is the one standing alone on this issue.

(This was brought up frequently in the comments in the 400s.)


612> 90% of my web surfing is gaming, a vast majority of which is 1 game
612> (itsagoal.com) of which a large proportion is reliant upon ALT
612> tooltips and having to press SHIFT+R every time I would like to
612> interpret a graphic into a readable figure is a sickener

Part of ITSAGOAL.com relies on what Vicent Flanders calls "mystery meat navigation" <http://www.webpagesthatsuck.com/mysterymeatnavigation.html>. 
They have a serious usability problem: they've made their site usable 
only by a subset of Windows users, those using Internet Explorer.

You'd probably get better results encouraging ITSAGOAL.com to fix their 
site rather than encouraging everyone to break their browsers -- to 
emulate what is now an IE/Win quirk.


612> I wonder how many others have done the same, thus 9/10 people
612> still using IE?

8/10 and dropping slowly.


612> IF Monzilla had for the past 5 years enabled ALT tooltips,
612> then how much greater could their market share be?  Possibly 
612> enough to throw its weight around and be able to dictate how
612> programmers should and shouldn't be writing their HTML?

That was not the fate of Netscape 4.
Don't be fooled into thinking that the hypocrites won't support alt because of standards. I was shocked when I found out that they don't render the MARQUEE according to standards (it should be ignored). See Bug 156979 and related for yourself.
614> Don't be fooled into thinking that the hypocrites won't support 
614> alt because of standards.

Don't be fooled into thinking that tooltipping the replacement text
violates HTML standards. As people arguing both pro and con have
repeatedly pointed out (including myself in comment #425), nothing 
in the standards prohibits rendering the replacement text at the 
same time as the image.

This is not a standards compliance issue. To comply with the
standards, a browser need only render the replacement text when 
the image will not be rendered. Mozilla does.

The reasons this bug is marked WONTFIX are in comment #31.
1.) These arguments are perfectly adaptable to the marquee issue or bug #391330 and the inconsistency in their handling is appalling.

2.) These arguments are for authors, not users. Users know nothing about standards, title attributes, wrong developer encouragement etc. They just see that pages that used to "work" in IE no longer "work" in FF.
616> 1.) These arguments are perfectly adaptable to the marquee issue

What arguments?

"Replacement text tooltips don't violate HTML standards" does not apply to marquee, which is not an element in valid HTML. 

"Replacement text tooltips discourage authors from providing replacement text at all" from comment #31 does not apply to marquee either.

616> and the inconsistency in their handling is appalling.

I doubt most users are as easily shocked and appalled as you.

616> [Users] just see that pages that used to "work" in IE no longer "work" in FF.

Good use of scare quotes. Many users who don't use Windows never see them "work" at all. What sites do you frequent that stop 'working' in Firefox?
I agree with the original poster. It is not about compliance to standards, it is about end user visibility. End user can turn off images display, and the ALT text then shows in the place of the images. By seeing a tooltip EVEN IF the image is properly displayed, we can get more descriptive information about what the web page author intended the image to mean. Search engine spiders and the semantic spiders will be able to understand the image better especially if it has a name like Image201.jpg. So standards can be wrong, because they are not meant for real browser users, they are meant for those people wearing heavy coats and making presentations and seminars to more people wearing suits and coats. I use Traffic Compressor, so my images are blurred to lose visibility but show some basic detail about the image while downloading very less of the image file, so I want to see what descriptive text the image author intended the image is for, even if the image is currently rendered.

http://www.useit.com/alertbox/9610.html
(In reply to comment #619)
> By seeing a tooltip EVEN IF the image is properly displayed, we can 
> get more descriptive information about what the web page author 
> intended the image to mean. 

By seeing a tooltip of the textual replacement even if the image is properly displayed, you generally see redundant, useless information (to reiterate an example from comment #382, "[Download]" popping over when you mouse over graphical button reading "Download"). This impedes usability and discourages authors from using the alt attribute at all (like Borland, see comment #442).

> Search engine spiders and the semantic spiders will be able to understand 
> the image better especially if it has a name like Image201.jpg. 

Then wouldn't it be best to encourage, not discourage, use of replacement text on images?

> So standards can be wrong, because they are not
> meant for real browser users, they are meant for those people wearing heavy
> coats and making presentations and seminars to more people wearing suits and
> coats.

As a member of the HTML Working Group, I have NEVER worn a heavy coat while giving or watching a presentation. Maybe the Opera folks from Oslo do that the Norwegian climate gets chilly.

> I use Traffic Compressor, so my images are blurred to lose visibility
> but show some basic detail about the image while downloading very less of the
> image file, so I want to see what descriptive text the image author intended
> the image is for, even if the image is currently rendered.

That's an interesting use case. Which brings to mind a more common one: in browsers that support progressive rendering, some images appear blurry when they start downloading and come into focus as they complete. Rendering the replacement text may be useful until the image has completely downloaded.
>By seeing a tooltip of the textual replacement even if the image is properly
>displayed, you generally see redundant, useless information

Disagree, even if it were redundant/useless, what if I wanted to see what is there in the ALT attribute? What if the web page author has not specified the TITLE attribute?

>This impedes usability and discourages
>authors from using the alt attribute at all

On the contrary, displaying ALT as tooltip (in the absence of TITLE) would improve usability.

>Then wouldn't it be best to encourage, not discourage, use of replacement text
>on images?

I am neither discouraging nor encouraging use of replacement text on images, but if it were present, there needs to be a way of rendering whats in it, even if the image itself got displayed.

The point about standards is that standards are not the only rules to live by, standards are made by a minority of people and standards are to be made based on how people use it. 

Rendering the replacement text needs tobe *in addition to* rendering the image itself, if it is not in TITLE, then display what is in ALT as tooltip..
Hi Everyone - I would really appreciate if someone could help me!
I put together my own website through Intuit - people are posting on my site things that I specifically asked them not to, so as a way of catching their eye one last time with the reminder, I added Alt Text all over the page they're posting the wrong stuff to. 
I am not a web designer, I don't know html and I have no money to hire a professional to build a site, so can someone PLEASE tell me in basic idiot terms how I can do what I'm trying to do. (Again, that is, to make those little boxes of text pop up when someone moves the cursor over the images.) 
I will be so grateful to anyone who can help - I'm at a loss :)
(In reply to comment #628)
> Hi Everyone - I would really appreciate if someone could help me!

This bug report is not a forum for getting help with HTML.

Use the "title" attribute instead of "alt" (or in addition to it.)
e.g.
<img src="x.jpg"  alt="description of image" title="this will be a tooltip">
You need to log in before you can comment on or make changes to this bug.