Closed Bug 88297 Opened 23 years ago Closed 21 years ago

ChromeTooltipListener should return ALT text when TITLE is not available

Categories

(Core Graveyard :: Embedding: APIs, defect)

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 25537

People

(Reporter: DebugWeyers, Assigned: adamlock)

References

Details

(Keywords: compat, topembed, Whiteboard: WONTFIX ? -- non standards compliant)

Attachments

(3 files)

Patch to ChromeTooltipListener that displays ALT attributes when TITLE attributes are not found
3.05 KB, patch
Details | Diff | Splinter Review
A second patch that creates a bool on nsIWebBrowserSetup to allow for ALT tooltips display, includes minor changes to DocShell
8.33 KB, patch
Details | Diff | Splinter Review
A fix of the last patch to confine changes to embedding module. Stores mAllowAltTooltips member on nsWebBrowser.
7.04 KB, patch
Details | Diff | Splinter Review 
I am working on an embedding client and the current nsIToolTipListener 
callbacks only pass along TITLE attributes.  The expected behavior is that a 
mouseover on an image or link displays the TITLE attribute, but, if no title is 
available, displays the ALT attribute (if any).  This behavior is evidenced in 
(and expected by) innumerable banner ads and web graphics.


Steps to reproduce:
Using an embedded client (mfcembed, winembed, etc.), move the mouse over an 
image with an alt tag and hover.

Expected result: A tooltip pops up and displays the contents of the alt tag.
Actual result: No tooltip is displayed.


The current implementation of this functionality is in nsDocShellTreeOwner.
{h,cpp}.  The class ChromeTooltipListener has a callback (sToolTipCallback) 
that checks for a TITLE attribute via FindTitleText().  I propose simply adding 
an OR statement to this check so that failure to find TITLE text will result in 
a check for ALT text.  If either is found, it is passed down the line to the 
tooltip listeners via ShowTooltip.
This function has been proposed and rejected many times before.  There is a
clearly delineated distinction in function between alt and title attributes; alt
attributes are to be used when the user agent *cannot* render the specified
content and displayed inline, while title elements provide additional
information which can be displayed in tooltips.  See bug 69877 and bug 25537 for
discussion of this.  Displaying the value of the alt attribute in a tooltip is
considered a broken and non-standards-compliant behavior and a deliberate
decision has been made not to do so.  This behavior should (IMO, and probably in
the opinion of the official standards-compliance team) also extend to other
Gecko-based clients.  QA, please WONTFIX.
Since its already been rejected many times, marking WONTFIX...
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I'm reopening this bug. I'm sure this could be made a pref via
nsIWebBrowserSetup that allows either behaviour. The default would be the
correct behaviour with the pref allowing the more IE/Netscape 4.x behaviour.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Also note that this bug is specifically for embedders who want to modify the
behaviour of how their tooltips are displayed.

It does not affect Mozilla the application which carries on doing the right thing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
I attached a proposed patch implementing things as per Adam's suggestion.  
Added bool to nsIWebBrowserSetup::SETUP_ALLOW_ALT_TOOLTIPS which sets a member 
on the docshell (the default of which is false, to maintain expected browser 
behavior).  sTooltipCallback in the ChromeTooltipListener now checks this bool 
before checking for ALT text to display.

I wasn't quite certain if there was a better way to get ahold of the docshell 
from the ChromeTooltipListener.  But I just wanted to get things moving on this 
patch.
Alex,

It would be better to store mAllowAltTooltips in the nsWebBrowser class and
leave nsDocShell alone. This confines the non-standard ALT behaviour to
embedding and is easier as well because the chrome listener already has a
pointer to mWebBrowser so it could use that to directly examine the value of
mAllowAltTooltips.
We should not be using ALT for tooltips, ever.  ALT is for alternate text. 
Letting authors know that it is for tooltips sends the wrong message and leads
them to create pages that are unusable on non-graphical browsers.  See

http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html

for more information.

I recommend that this bug be resolved as WONTFIX.
See bug 1995 for the original discussion of this issue.
I think we all understand what the standard is and what the correct use of the 
ALT attribute is. However, the fact remains that thousands, if not hundreds of 
thousands, of web sites already exist that will show the ALT attribute as a 
tooltip if the a TITLE attribute is not available. This is because MSIE and 
previous releases of Netscape Navigator both  implemented it.

To close this bug as WONTFIX is unacceptable to embeddors. Mozilla won't 
display the ALT tags as tooltips, nor will NS Navigator (unless either choose 
to do so). Allowing embeddors the option to display them is a good idea.

Navigator (and mozilla) will be able to claim standards compliance by not 
showing ALT attrs as tooltips, but to the end user it will simply appear to be 
another bug....because IE does it and Nav does not. That won't help grow 
marketshare.

Even Netscape's home page is guilty of putting "Click here!" ALT attrs over 
advertisements.

At this point, showing ALT attrs is pretty much an expected behavior, mostly 
due to site developers who don't know any better, and use IE for testing. 
Embeddors should have the option.

If you want to embed an engine that disregards the standards in order to take
over the web, go embed IE, not Mozilla.  (My personal opinion only, I guess.)

(I also don't see the evidence that there are large numbers of sites that depend
on this.  Even if they do, tooltips aren't that important since the user rarely
notices them.)
Whiteboard: WONTFIX ? -- non standards compliant
My ActiveX control is one embedding example that would like to have a switch to
loosen the tooltip behaviour. As stated before, the default would be to only use
TITLE tags and the embedder would have to explicitly enable ALT tag tooltips.
Why do we need to bloat the code with a series of prefs where the default is "do
X right" and the pref can be changed to "do X wrong"?
I think one of the problems here is that Mozilla has a "quirks" mode.  If there
were no quirks mode at all, it'd be very easy to say that everything should
conform to the standard, and evangelism should take care of any web pages that
cause problems.  But because of quirks mode, I suspect most people feel that
requests like this one should at least fit somewhere into the browser.

Ultimately, doesn't the fact that this request comes up again and again (and
again) say something?
Quirks mode should be (and generally is, although some quirks have slipped in
that shouldn't have) limited to those problems where we have serious problems on
significant numbers of pages if we didn't implement the quirk.  I don't see
evidence that this qualifies (not very serious, and not many pages).

Could you quantify "again and again"?
Dbaron, a quick search shows these bugs for the same issue: 25537 47575 66282
67093 74241 74376 78575 79996. Your definition may be different than mine, but
this fits "again and again" for me :)

One reason I would like to see this implemented is that, when writing an HTML
page, I currently have to provide both ALT and TITLE to get a tooltip to show up
on an image, because a good number of people still use Netscape 4.x. If I omit
the ALT text, then NS4x users don't see a tooltip, but Mozilla and IE users do.
If I omit TITLE, then NS4x, IE, and Opera users see a tooltip, but Mozilla users
don't. I'd hate to tell people to use IE, and Mozilla is still not at that stage
that I'd recommend it to, say, my parents or my less technically proficient friends.

Maybe the question I should ask is: do you have a suggestion of how I can get an
image to display a tooltip on all *relevant* browsers (IE, NS4x, Mozilla, Opera)
without using ALT at all?
Out of all those bugs you mentioned and a number of other bugs you didn't
mention that were marked duplicates of those bugs, there were only three cases
other than this bug where people disagreed after learning why we behave the way
we do (bug 61222, bug 67093, and bug 74241).  So most of those bugs were the
result of people who were uninformed but agreed with our behavior once informed
of our reasons.
Dbaron, the reporter simply stayed silent in some of the bugs, like bug 25537,
bug 47575, bug 66282, and bug 74376.  I respectfully suggest that this is not
the same as agreement :)  Certainly when I reported this, I finally just shut up
because it didn't matter if I felt there was good reason for the request, it was
obvious I could not convince the "powers that be"

Again, I would really like to know if anyone can suggest a way to make all the
current, relevant browsers display an image tooltip without using ALT.  If not,
then I suggest that until and unless you can wipe Netscape 4.x off the market
completely, there will be people expecting this behavior from their browser.

Finally, reading over the W3C specs for IMG and ALT (as hixie has suggested in
some of the other bugs), I don't see anything to suggest that the ALT text
*cannot* be used for a tooltip.  It simply says that the ALT text is required
for non-visual browsers, but does not explicitly prohibit using it for an
additional display.
> Certainly when I reported this, I finally just shut up
> because it didn't matter if I felt there was good reason for the request, it
> was obvious I could not convince the "powers that be"

Even if that's the case, it still seems like the people who want ALT attributes
displayed as tooltips are a minority.  (Notice the various people who have
argued against it.)

> Again, I would really like to know if anyone can suggest a way to make all the
> current, relevant browsers display an image tooltip without using ALT.  If
> not, then I suggest that until and unless you can wipe Netscape 4.x off the
> market completely, there will be people expecting this behavior from their
> browser.

If we start displaying ALT attributes, then people will expect us to continue
doing so after Netscape 4.x is off the market, since there will be more pages
than there are now that "depend" on ALT.  (I quoted "depend" since tooltips are
unlikely to help most users figure out how to use web page interfaces.)

> Finally, reading over the W3C specs for IMG and ALT (as hixie has suggested in
> some of the other bugs), I don't see anything to suggest that the ALT text
> *cannot* be used for a tooltip.  It simply says that the ALT text is required
> for non-visual browsers, but does not explicitly prohibit using it for an
> additional display.

As I've said before (in other discussions), I think my desk is a conformant HTML
4.0 user-agent since it does not behave differently in an observable macroscopic
way when I tap different SGML-equivalent documents on it in morse code.  While
displaying ALT attributes as tooltips is not against the letter of the spec it
is very strongly against the spirit of the spec, since ALT attributes are
intended to be used to provide alternative text for when the image cannot be
displayed (which means that displaying both text and image would be redundant).
 If we continue to teach authors that ALT attributes are for tooltips we will
contribute to making the web unusable for blind people and people with slow
connections in other parts of the world.

For lack of an HTML standards-compliance module owner for Mozilla, taking the
initiative and marking INVALID.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
This is a feature that is requested in embedding and that I personally need.
Therefore I am reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
That you say it's "requested in embedding" scares me a lot.

I guess the standards compliance folks can just start making changes to
embedding interfaces too, right? :-)
standards compliance folks are welcome (as is _anyone_) to suggest modifications
to interfaces "UNDER_REVIEW" or "FROZEN".

IMHO, this boils down to the "quirks mode" slipperly slope. We slipped a looong
time ago. It's an option w/ the "standard" behavior as the default.
This issue is much more fundamental than anything in quirks mode.  It's about
whether Mozilla is going to be yet another graphical web browser that encourages
authors to write pages only for similar browsers, or whether it will help move
towards some of the original intentions of the Web.

If we have yet another browser that displays ALT text as tooltips, it will
discourage authors from using correct ALT text because they will see it appear
as tooltips and it will encourage authors to use inappropriate ALT text so that
it will appear as a tooltip.

This gets down to the reasons why I started working on the Mozilla project in
the first place -- the promise of something better for the Web than the browsers
before it.  I'm having trouble thinking of why I should continue to work on the
project if we give up on that.  Every time I comment on this bug I get angry
because I have the feeling I'm losing everything for which I've worked so hard
over the past three years.
Looks good, r=adamlock@netscape.com
David, welcome to the eternal dilemma :-). I share the same pain (try building a
networking library based on specs and rfcs :-)). The balance between "the right
thing" and "the market place" is obviously hard. I'm personally coming at this
dilemma from the necko side where time after time after time, we've had to
deviate from specs and standards. It's to the point now that I don't even bother
looking at specs for verification that I'm already familiar with :-(.

Several years ago mozilla had to decide whether or not it was going to have to
deviate from standards to make a viable (measured in terms of marketshare)
product. That decision wound up conceeding quirks mode, a networking lib that
isn't "spec", and obviously a variety of other things that aren't "perfect."
Day-to-day all I can hope for is that the majority of what I do is standards
compliant :-/.
I think this really ought to go to the newsgroups. I think this comes down to an
issue of whether mozilla.org will arbitrarily accept patches that allow the
browser to deviate from standards. The answer to that question is important to
mozilla.org's legitimacy as a promoter of Web standards. It is clear that
"tooltip" text is not consistent with the notion of "alternate content" as
specified for the application of the ALT attribute. Thus the only "gain" from
this patch is promotion of the Wrong Thing.

(And changing OS to All, as this will surely affect everyone.)
OS: Windows 2000 → All
Keywords: topembed
My problem with this isn't so much that we have places where we're forced to 
compromise standards compliance to have a browser that actually browses, but 
that we're creating inconsistency between the standards compliance of Mozilla-
the-browser-and-other-good-stuff, and browsers that use Gecko.  This is all the 
more so because Mozilla isn't supposed to be an end-user product (or so I keep 
hearing)-that's the job of Netscape, Beonex, the embedders, etc.

Gecko should have a consistent level of standards compliance, whether it's in 
Mozilla, Netscape, Beonex, or anything else-otherwise web designers will just 
have to resort to weirder and more obfuscated browser-sniffing hacks to work 
around the different quirks introduced by different Gecko-based browsers.  If 
embedders feel strongly about this particular quirk, it should be brought in 
front of the entire Mozilla community for discussion, and, if their arguments 
are compelling enough, it should be added to quirks mode for the entire 
browser.  What should NOT be happening is a balkanization of the layout engine 
caused by prefs like this.

I heartily agree with the suggestion that this be brought to newsgroups-this is 
a major policy issue, and it shouldn't be quietly slipped into the tree without 
warning or discussion.
> standards compliance folks are welcome (as is _anyone_) to suggest modifications
> to interfaces "UNDER_REVIEW" or "FROZEN".

There's a big difference between suggesting changes and trying to slip them in
without anyone noticing.


c'mon. who's trying to "slip" anything in? that's pretty hard to do in
open-source even if someone wanted to. again, balance is key here. we can't go
through review of _every_ modification that goes into the tree. that would
ultimately boil down to voting on mods which is a sure way to grind things to a
halt.

I'm doing the best I can to ensure that mods to embedding related interfaces get
public exposure for review. I send mail to .embedding/.porkjockeys _everytime_
there's a scheduled API review. I've offered up temporary badges to non-NS folks
who want to physically attend. There's a 800 number for _anyone_ that wants to
dial in, etc.

I'm sorry if you feel things are being "slipped" in.
> I'm sorry if you feel things are being "slipped" in.

I said that I thought you were *trying* to slip them in.  If choess hadn't
mentioned the existence of this bug to me, there would have been no controversy
and I probably would have found out sometime after it landed, as would everyone
else who was involved in the original decision.
Judson: what I find most serious about this bug is that a major policy decision  
is being made, implicitly, without any airing.  The problem is not that major 
changes to embedding are not sufficiently open;  the problem is that we will 
potentially have embedded clients with a different level of standards compliance 
than Mozilla *on the same page*.  Showing "alt" attributes in tooltips is hardly 
the most popular "4.x did it the wrong way and we want you to do it the wrong 
way" issue; this relatively minor embedding change opens a major can of worms in 
allowing embedders to do things "the wrong way".  Please, whatever you may think 
of the arguments for whether or not this is standards-compliant behavior, don't  
set up the potential for different levels of compliance in "Mozilla" Gecko and 
embedded Gecko; from a web designer's perspective, this is a disaster in the 
making.

Adam: I'm curious. Why do you feel that "This is a feature that is requested in 
embedding and that [you] personally need."? Feel free to e-mail me directly at
ianh@netscape.com if the reasons are AOL-confidential.
Keywords: compat
My ActiveX control is meant to be a drop-in replacement for the IE control so I
would like the tooltip behaviour to be the same. I have also received emails and
seen enough talk of tooltips in the npm groups to know there will be other
embedders who want it too.
Would you also like the CSS rendering to be the same?
choess: I couldn't agree more w/ the point you're making. Mozilla is indeed the
standard to be used by embeddors, if Mozilla goes off course (on it's own or by
embedding forces pulling on it), everyone goes off course :-/.

The trick is balancing these forces; sometimes it's easy (most of the time),
sometimes it's not. I wish I had a real response :-/.
Alright, this "bug" has been troubling my sleep and digestion for days, and I'll
be away from the network for a while, so let me give here my full Reasons Why This
Should Not Be Checked In.

1) We should not be showing "alt" text in tooltips.  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.

2) To be very blunt (forgive me; as I said, I'm tired and cranky), I think the
arguments we've seen here, "To close this bug ... is unacceptable to
embeddors[sic]," "I would like the tooltip behavior ... to be the same as IE,"
are, quite frankly, complete BS.  It's not as if, say, all the links on the page
stop working because someone forgot to close the "head" element; one small,
auxiliary feature (the tooltip) "breaks" in the sense that you have to include
tooltip text in two attributes, not one.  (While I'd rather not see people
duplicating "alt" and "title" attributes when that behavior is inappropriate,
some web authors have other priorities; that's their lookout, not mine).  I
submit that any "bug" which can so easily be worked around by authors is *NOT*
essential to "fix".

Rant over, the more important arguments, I think, are:
3) Why is it that this is somehow essential for embedding and not for
non-embedded products (Netscape, Beonex, etc.)?  All of them are browsing the
same web, on the same types of machines and operating systems-if this is really
necessary, it should be brought back up for discussion and be entered into
Quirks Mode in layout so that everything behaves uniformly.

4) Continuing on this theme, does it justify forking our standards support?  If
we commit to this, we open the door for Gecko-embedding browsers having
different levels of standards compliance from Mozilla/Netscape/Beonex, etc. and
one another, creating a compatibility nightmare for web designers trying to keep up.

5) Why is this, and not other backwards-compatibility-breaking issues, such a
problem for embedders.  Anyone embedding Gecko has already accepted our
non-support for "layer" &etc., as well as document.all (to name two off the top
of my head); I realize this is a terrible thing to say in front of customers,
but maybe if it's essential that you have more backwards compatibility than
enough to keep the page from destroying itself (quirks mode), you should look
into embedding another HTML renderer.

This pretty much sums up my arguments: I'm sorry I haven't been more objective
and polite about this, but I'm tired of arguing an issue I thought had been
decently laid to rest long ago.  Please, PLEASE, consider some alternative to
this; I know I've said this over and over, but this has much broader effects
that just a minor embedding change, or a behavior only a few
standards-compliance people care about.

And to the embedding folks: thanks for all your work.  I know I bitterly
disagree with you about this bug, but I do appreciate what you've done to make
Gecko more useful.  Please WONTFIX this bug...but keep up the good work! :)
Some community sites in Sweden (for example www.lunarstorm.se) uses this
feautre/bug and it's really annoying that mozilla doesn't have this. While this
is not standard the fact is still that alot of webpages uses this in some way or
another to provide information. I do agree it is not correct way of doing things
but I still think this feature/bug should be added atleast as a option. As we
all know alot of people are using the IE browser and many webdesigners are using
IE only to test the work they do we have to be flexible to allow such stupidity
to exist.. else people like myself will have to use Netscape 4/IE on alot of
sites out there and not mozilla :/
Fix is checked in...








Only kidding, marking WONTFIX.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Adam, your restraint is very much appreciated.  I won't have access to the 
newsgroups for a few days, but when I get back, I'm going to propose that we:
1) Add material on alt/title tooltips to ekrock's standards compliance page.
2) Accept "tooltips don't work on this page"-type bugs as Evangelism bugs, so 
people aren't just getting turned away without help when this occurs.
VERIFIED WONTFIX.
Status: RESOLVED → VERIFIED
I've been asked (for the record) to paste in the following email message I sent
that summarized my arguments:

> [...]

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.
Is it possible to make this a quirks mode only thing? After all quirks mode
doesn't follow standards but tries to emulate NS4.
The goal of quirks mode is not to emulate NS4.  That would require *tons* of
quirks.  The goal of quirks mode is to deviate from standards when (and only
when) not doing so would make us unable to handle real web pages correctly.

Also see my comments above, which apply equally to quirks mode.
*** Bug 109410 has been marked as a duplicate of this bug. ***
+1 vote to display ALT text as tooltip, when TITLE is not available
Just a thought, in case anyone is still paying attention to this bug.  Maybe
there is some way to emulate this behavior without making any core changes to
Mozilla.  Like adding some javascript hook that runs after each page load to
walk the DOM tree and set the tooltip for each image object to the ALT value. 
Seems like a lot of controversial features could be implemented in this sort of
non-intrusive way.
well if you insist that you want to see alt as tooltip, see
http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en
Yeah, I use that plugin for Mozilla. Gets around the diamond mine anals on the
Mozilla project. Highly recommend it.
Except that 80%-90% of the Mozilla users even does not know that such popupalt
plugin exists.
And they will simply say: Mozilla is ****! It even can not display the tooltip,
what Internet Explorer displays correctly. Users don't know about standards, nor
they bother about it. They will simply uninstall Mozilla, and say their friends,
Mozilla is a ****! Period.

Mozilla will be never widely successful, until it will not have built-in support
for traditional feature, like ALT tooltip display (when TITLE is not available).
Though I agree Mozilla should show Alt attributes as a Tooltip at least as an 
option, I disagree with your arguments WebMaster33.


1) Users don't know about standards, nor they bother about it.

Well Mozilla is for developers. I hope they know about standards. If they're a 
developer, Mozilla may be their introduction to standards (clearly a goal of 
the authors), and if they don't like standards, then they indeed will not use 
Mozilla - and its authors won't miss such users.

Netscape 7 on the other hand is quite different. As it's intended for the 
masses, I agree, those users should not be forced into a standards-anal 
experience.


2) Mozilla is a ****!

I doubt that. I care about Mozilla's feature set because it's my favorite 
browser. Presumably the same is the case for you, and the other more than 100 
users commenting on this bug and its Dupes. And with the Alt Plugin (easy to 
install thanks to Mozilla's sweet XPI architecture), it's near-perfect.


3) 80%-90% of the Mozilla users even does not know that such popupalt plugin 
exists.

Well, if it is important to them, they can find this bug and, with sufficient 
patience, the link to the Alt Plugin.

However, it did take me a long time to realize Mozilla was consistently not 
recognizing the Alt attribute. I had assumed the browser was broken, or that it 
was a feature meant for later. This is a lacking feature anyone new to Mozilla 
would expect, and if the anal people running this boat seriously won't include 
Alt Tooltips into the main codebase, they should at least include a warning in 
the Readme. that this feature isn't implemented, and where to get the Plugin to 
resolve the issue.
Answer to Comment #52:
1) Mozilla is for developers
No. Mozilla is not just for developers! Mozilla is for any user, who want a
small, fast browser, with fine features!

2) 
>>Mozilla is a ****!
I DID NOT say that!!! I said, users who don't know why ALT is not displayed will
say that...

>I had assumed the browser was broken, or that it 
>was a feature meant for later. 
You just proved the statement I said, that people would think: Mozilla is a
****. You thought it's broken. It's the same.

Even IE has the option to turn ON/OFF ALT tooltip displaying: 
Accessibility/Always expand ALT text for images.
By default it's turned OFF.
It would be so easy to have implemented as option in Mozilla, too.
And if would be turned OFF by default, similarly like in IE, it would not hurt
anybody, but those users like me, who misses this feature would get their small
missed feature.
Mozilla would support this way a traditional feature. Optionally.
I can't believe that a turned off feature would disturb Mozilla developers so
much, that they don't want to implement it.
Reopening to mark as a dup of bug 25537.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---

*** This bug has been marked as a duplicate of 25537 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
Request for a specific implementation of #25337. Verifying duplicate.
Status: RESOLVED → VERIFIED
By the way, there's an error in the first patch that duplicates FindTitleText()
as FindAltText() changing instances of "title" to "alt". It also duplicates the
part checking the XLink namespace if there's no title found in the root namespace.

While there is an 'xlink:title', there is no 'xlink:alt', so the XLink check in
FindAltText() wastes cycles to no purpose.
*** Bug 230064 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: