Bug 25537 (NoTooltip)

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

VERIFIED WONTFIX

Status

()

--
enhancement
VERIFIED WONTFIX
19 years ago
2 years ago

People

(Reporter: rmurray, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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.

Comment 1

19 years ago
I don't tooltips are planned until post beta:
see bug 22511
Component: Browser-General → XP Toolkit/Widgets

Comment 2

19 years ago
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
Last Resolved: 19 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

Comment 4

19 years ago
*** Bug 50727 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
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. ***

Comment 7

18 years ago
*** Bug 74376 has been marked as a duplicate of this bug. ***
*** Bug 78575 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
*** Bug 79996 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
*** Bug 84066 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
*** Bug 87121 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
*** 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
Last Resolved: 19 years ago18 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

Comment 18

18 years ago
*** Bug 90821 has been marked as a duplicate of this bug. ***
*** Bug 94708 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 95694 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 96109 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
"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. :)

Comment 23

18 years ago
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

Comment 24

18 years ago
*** Bug 96608 has been marked as a duplicate of this bug. ***

Comment 25

18 years ago
*** Bug 97774 has been marked as a duplicate of this bug. ***

Comment 26

18 years ago
should this still have the "verifyme" keyword?  
(the bug show Status:Verified, and Resolution: invalid)

Comment 27

17 years ago
*** Bug 99014 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
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. ***

Comment 30

17 years ago
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
Last Resolved: 18 years ago17 years ago
Resolution: --- → WONTFIX

Comment 32

17 years ago
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.

Comment 34

17 years ago
*** Bug 113486 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
*** Bug 117089 has been marked as a duplicate of this bug. ***

Comment 36

17 years ago
*** Bug 117519 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
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.

Comment 38

17 years ago
Created attachment 63127 [details]
Screenshot of an alt tooltip on http://news.bbc.co.uk/ with Communicator 4.0
Dan please file a bug on evangelisation for the BBC site.
For a discussion of why this bug is WONTFIX, see comment 31.

Comment 40

17 years ago
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. 

Comment 41

17 years ago
*** 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. ***

Comment 45

17 years ago
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.

Comment 47

17 years ago
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.

Comment 50

17 years ago
*** Bug 136542 has been marked as a duplicate of this bug. ***

Comment 51

17 years ago
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".

Comment 52

17 years ago
> 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....

Comment 54

17 years ago
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.

Comment 55

17 years ago
<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 ?
</>

Comment 56

17 years ago
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...

Comment 58

17 years ago
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...

Comment 60

17 years ago
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)

Comment 62

17 years ago
*** Bug 139495 has been marked as a duplicate of this bug. ***

Comment 63

17 years ago
*** Bug 140015 has been marked as a duplicate of this bug. ***

Comment 64

17 years ago
*** Bug 141997 has been marked as a duplicate of this bug. ***

Comment 65

17 years ago
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.

Comment 67

17 years ago
Yea well the dont and it anoying and it would require more code to be written 
Maybe iI should complain to W3C?

Comment 68

17 years ago
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. ***

Comment 71

17 years ago
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.

Comment 74

17 years ago
> - 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.

Comment 75

17 years ago
*** Bug 143421 has been marked as a duplicate of this bug. ***

Comment 76

17 years ago
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.

Comment 78

17 years ago
There Probably not going to fix this.
So is there a pach availible?

Comment 79

17 years ago
>....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.

Comment 80

17 years ago
*** Bug 144987 has been marked as a duplicate of this bug. ***
*** Bug 145068 has been marked as a duplicate of this bug. ***

Comment 82

17 years ago
*** Bug 145415 has been marked as a duplicate of this bug. ***

Comment 83

17 years ago
(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"

Comment 84

17 years ago
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.

Comment 86

17 years ago
*** Bug 147186 has been marked as a duplicate of this bug. ***

Comment 87

17 years ago
*** Bug 147357 has been marked as a duplicate of this bug. ***
*** Bug 147413 has been marked as a duplicate of this bug. ***

Comment 89

17 years ago
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."

Comment 90

17 years ago
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).

Comment 92

17 years ago
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).

Comment 97

17 years ago
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?

Comment 99

17 years ago
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.

Comment 101

17 years ago
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 → ---

Comment 102

17 years ago
Oops sorry I dont know how I reopend this I never thought I havr the right

Comment 103

17 years ago
Alex Hosking, please stop spamming the bugs. The newsgroups
are the appropriate place for most of your comments.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 104

17 years ago
hehe
Status: RESOLVED → VERIFIED

Comment 105

17 years ago
Resolved?
This really sucks

Comment 106

17 years ago
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. ***

Comment 108

17 years ago
*** Bug 152813 has been marked as a duplicate of this bug. ***

Comment 109

17 years ago
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 → ---

Comment 110

17 years ago
Try reading the bug Mr. Joseph Brown
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 111

17 years ago
suggested reading: comment 31 and comment 95 for example. v.
Status: RESOLVED → VERIFIED

Comment 112

17 years ago
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.

Comment 114

17 years ago
*** Bug 155101 has been marked as a duplicate of this bug. ***

Comment 115

17 years ago
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

Comment 118

17 years ago
*** Bug 157972 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Alias: NoTooltip

Comment 119

17 years ago
*** Bug 158478 has been marked as a duplicate of this bug. ***

Comment 120

17 years ago
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.

Comment 122

17 years ago
*** Bug 159698 has been marked as a duplicate of this bug. ***

Comment 123

17 years ago
*** Bug 159831 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Summary: alt tags are not displayed as tooltips → alt text is not displayed as a tooltip

Comment 124

17 years ago
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.

Comment 125

17 years ago
*** Bug 160245 has been marked as a duplicate of this bug. ***

Comment 126

17 years ago
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. ;-)

Comment 128

17 years ago
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.

Comment 129

17 years ago
*** 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. ***

Comment 132

17 years ago
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.

Comment 133

17 years ago
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.

Comment 135

17 years ago
*** Bug 163411 has been marked as a duplicate of this bug. ***

Comment 136

17 years ago
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.

Comment 137

17 years ago
>> 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

Comment 138

17 years ago
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.

Comment 139

17 years ago
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.

Comment 140

17 years ago
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.

Comment 141

17 years ago
> 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.

Comment 142

17 years ago
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?

Comment 143

17 years ago
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.

Comment 144

17 years ago
=========== 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.

Comment 145

17 years ago
*** Bug 164291 has been marked as a duplicate of this bug. ***

Comment 146

17 years ago
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.

Comment 147

17 years ago
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.

Comment 148

17 years ago
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.

Comment 149

17 years ago
Make that bug 41924, not 1924. Sorry.

Comment 150

17 years ago
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.

Comment 151

17 years ago
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.

Comment 152

17 years ago
> 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!!!)

Comment 154

16 years ago
*** Bug 165451 has been marked as a duplicate of this bug. ***

Comment 155

16 years ago
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. ***

Comment 157

16 years ago
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.)

Comment 158

16 years ago
*** Bug 167975 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 163993

Comment 159

16 years ago
Just filed bug 172253, RFE: show alt text in status bar.

Comment 160

16 years ago
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

Comment 161

16 years ago
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.

Comment 162

16 years ago
>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.)

Comment 164

16 years ago
>> 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

Comment 165

16 years ago
> 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.

Comment 166

16 years ago
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.

Comment 168

16 years ago
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.

Comment 169

16 years ago
Oops, too many "up"s.   popupalt.xpi from
http://www.cc-net.or.jp/~piro/xul/_popupalt.en.html

Comment 170

16 years ago
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.)

Comment 172

16 years ago
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

Comment 173

16 years ago
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.

Comment 174

16 years ago
>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.

Comment 175

16 years ago
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.

Comment 177

16 years ago
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?

Comment 178

16 years ago
I absolutely aggree with reason of Comment #177 From Craig. Clean & well-founded
opinion.

Comment 179

16 years ago
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.

Comment 180

16 years ago
<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.

Comment 182

16 years ago
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".

Comment 184

16 years ago
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

Comment 185

16 years ago
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.

Comment 186

16 years ago
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?

Comment 188

16 years ago
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.

Comment 189

16 years ago
> 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 190

16 years ago
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.

Comment 191

16 years ago
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

Comment 192

16 years ago
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.

Updated

16 years ago
Component: Layout: Tables → Layout

Comment 194

16 years ago
Shut up
*** Bug 177061 has been marked as a duplicate of this bug. ***

Comment 196

16 years ago
*** Bug 177347 has been marked as a duplicate of this bug. ***

Comment 197

16 years ago
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

Comment 198

16 years ago
*** Bug 178121 has been marked as a duplicate of this bug. ***

Comment 199

16 years ago
*** Bug 181771 has been marked as a duplicate of this bug. ***

Comment 200

16 years ago
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.

Comment 207

16 years ago
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.

Comment 208

16 years ago
*** Bug 184489 has been marked as a duplicate of this bug. ***

Comment 209

16 years ago
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.

Created attachment 108996 [details]
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. ***

Comment 218

16 years ago
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.

Comment 221

16 years ago
*** Bug 187407 has been marked as a duplicate of this bug. ***

Comment 222

16 years ago
*** Bug 187657 has been marked as a duplicate of this bug. ***

Comment 223

16 years ago
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.

Comment 225

16 years ago
*** Bug 187883 has been marked as a duplicate of this bug. ***

Comment 226

16 years ago
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.

Comment 227

16 years ago
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

Comment 228

16 years ago
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

Comment 232

16 years ago
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. :-)

Comment 234

16 years ago
*** Bug 191728 has been marked as a duplicate of this bug. ***

Comment 235

16 years ago
*** Bug 192494 has been marked as a duplicate of this bug. ***

Comment 236

16 years ago
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

Comment 237

16 years ago
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. ***

Comment 239

16 years ago
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.

Comment 241

16 years ago
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.

Comment 244

16 years ago
"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?

Comment 246

16 years ago
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

Updated

16 years ago
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.

Comment 249

16 years ago
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

Comment 250

16 years ago
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.

Comment 252

16 years ago
"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.

Comment 258

16 years ago
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

Comment 259

16 years ago
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.

Comment 263

16 years ago
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.

Comment 270

16 years ago
*** Bug 197603 has been marked as a duplicate of this bug. ***

Comment 271

16 years ago
*** Bug 199126 has been marked as a duplicate of this bug. ***

Comment 272

16 years ago
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.

Comment 273

16 years ago
*** Bug 200266 has been marked as a duplicate of this bug. ***

Comment 274

16 years ago
*** Bug 201119 has been marked as a duplicate of this bug. ***

Comment 275

16 years ago
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.

Comment 278

16 years ago
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.

Comment 282

16 years ago
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.

Comment 287

16 years ago
Super this package  http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en
fix the problem with atl attribute.

Comment 288

16 years ago
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.

Comment 289

16 years ago
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 :)

Comment 292

16 years ago
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...

Comment 293

16 years ago
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.

Comment 295

16 years ago
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.

Comment 296

16 years ago
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.


Comment 297

16 years ago
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.

Comment 299

16 years ago
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.

Comment 300

16 years ago
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.

Comment 302

16 years ago
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.

Comment 305

16 years ago
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.







Comment 306

16 years ago
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.


Comment 307

16 years ago
<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".

Comment 310

16 years ago
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.

Comment 313

16 years ago
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.

Comment 315

16 years ago
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.

Comment 317

16 years ago
"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?

Comment 319

16 years ago
>>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.

Comment 321

16 years ago
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!!!

Comment 322

16 years ago
Correction: "5.x, 6.x" was meant correctly: "IE 5.x, 6.x"

Comment 323

16 years ago
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

Comment 324

16 years ago
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.

Comment 325

16 years ago
>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.)

Comment 328

16 years ago
>>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.

Comment 331

16 years ago
>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.

Comment 334

16 years ago
"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.

Comment 335

16 years ago
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.

Comment 337

16 years ago
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.

Comment 338

16 years ago
>>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.

Comment 341

16 years ago
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?

Comment 345

16 years ago
"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.
Created attachment 124200 [details]
Document containing a summary of bug comments - Read before commenting

"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! ;-)

Comment 350

16 years ago
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. :-)