K-meleon shows the value of the alt attribute as a tooltip in a very Microsoftish way. Why? Moz doesn't do this.

This 'enhancement' of HTML has been a bother for a long time now, forcing authors to add an empty title attribute to every darn image to make the alt balloons go away.

ALT is for alternate, that is it should be displayed when the image can't be loaded, not when it can. TITLE is for tooltips.

Would you please, please zap it? Pretty please? :-)

I agree. It hasn't annoyed me much but since somebody brought this up I tend to agree.

Agreed.
I can understand the desire for eg a [ ] display alt as tooltip checkbox in the preferences, if you visit a webpage where the author doesn't know what he is doing and you need to see the alt-texts.
But having alt = title by default is very bad from an accessibility standpoint.

This is very much a religious point of view or even a Taleban Tendency. The MS Imperialistic use of ALT tooltips has led to an improvement in the way many webpages can be viewed. Yahoo, Google and AOL use them. Why should petty hatred of MS result in starker, Talebanised pages? God bless America.

> The MS Imperialistic use of ALT tooltips has led to an improvement in the way many webpages can be viewed.

Improvment? In what way?
There already is a attribute to create tooltips that works in basicly all modern graphical browsers. It's called TITLE.
Why would you need two attributes to do the exact same thing?

> Yahoo, Google and AOL use them.

Um ALT is a REQUIRED attribute for <img>, so obviously sites use them...
However their job is not to provide tooltips (for which title should be used).

Difference between ALT and TITLE is very clear and has nothing to do with MS hating.

Suppose you have navigation images on your page, two arrows, one pointing left and meaning "previous topic" and one pointing right meaning "next topic". Now, ALT values for those images should be "green arrow, pointing left" and "green arrow, pointing right". TITLE values should be "previous topic" and "next topic".

ALT must describe the image itself when browser can't display it, not it's function.

For tooltipping use TITLE because TITLE can applied to almost element (you can apply TITLE to headers, links, buttons, divs etc) unlike ALT.

> The MS Imperialistic use of ALT tooltips has led to an improvement in the way many webpages can be viewed.

MS? Netscape4.x does it to. I didn't mention it because it's now of very limited interest what Netscape4.x does and does not.

Improvement indeed! Having every second WYSIWYG page display 'spacer.gif' all over is really neat. Not to speak of having it read it aloud to you.

No mercy - zap it! :-)

The sensible decision would be IMHO to render as a tooltip the content of TITLE when present and if it were missing, the content of the ALT. That would that problem in a - I must say - gracious manner ;-)
The IEEE specifications don't say anything about what should be in a tooltip in a given browser BTW. They state that it's up to the user agent.

Check this link to test your browsers:
http://www.petesguide.com/WebStandards/tests/tooltips.html

/Phil

> The IEEE specifications...

So?
I write webpages according to the W3C Specs, which is the recognized & uncontested authority in the field.
alt = a text replacement for the image.
title = extra info for a tag to be show eg as a tooltip.

A perfectly ok title for <img> would be "Cool picture isn't it!?!"
The same text for alt is pretty meaningless since you only see it when the image is NOT shown.

When you have browsers show alt as title, confused webdevelopers start adding meaningless alt-text becuse they might actually _belive_ the reason for alt is to provide popups.

I'm not contesting the specifications at all Stefan!
The problem is not to discuss the way web pages are written, it's to improve K-Meleon in a way that makes users' browsing experience as comfortable as possible.
Althought I agree with you Stefan that the content of the ALT attribute should not be in the tooltip in a perfect world, however as you already know, we are not in a perfect world ;-)
I therefore maintain my suggestion to make the tooltip list the content of the TITLE attribute when it's provided in the page, BUT when it's missing the tooltip should still display something. I propose to fill it in that case - and only in that case - with the ALT attribute content.
I don't see why this would cause any problem. I only see advantages to that: we follow the logic of the official specification (using the TITLE in priority) and as a backup, we have a mechanism to accomodate the reality of the Internet today (make non "correct" already existing pages usable).

/Phil

> however as you already know, we are not in a perfect world ;-)

*sniff* I can at least dream can't I



Anyway, my point still remain what I wrote in my first post in this thread:
----
I can understand the desire for eg a [ ] display alt as tooltip checkbox in the preferences, if you visit a webpage where the author doesn't know what he is doing and you need to see the alt-texts.
But having alt = title by default is very bad from an accessibility standpoint.
----

The optional checkbox IMO would be the solution that "covers all bases". It would alow users to see alt as popups if they wish but still remind a developer that it's the wrong way to do it.

"The optional checkbox IMO would be the solution that "covers all bases". It would alow users to see alt as popups if they wish but still remind a developer that it's the wrong way to do it."

No, that would keep less savvy authors doing this. If the functinality of a site depends on tooltips being displayed there is something fundamentally wrong anyway.

I'm not nitpicking. I just don't like to see K-Mel as the bad boy.

The fact that browsers such as Mozilla and Opera don't show alt text as pop-ups might, as with so many other 'features' of IE, lead the less informed designer to conclude that there is some functionality missing from them.

In the struggle to grab a share of the browser market, you can hardly blame developers for including features that users have become accustomed to.

Why else would Mozilla support MARQUEE? Why in Phoenix does 'Preferences' suddenly appear under the tools menu?

If you consider this, then K-Mel, at least in the majority opinion with regards to this matter, might come out as the 'good boy'.

"The fact that browsers such as Mozilla and Opera don't show alt text as pop-ups might, as with so many other 'features' of IE, lead the less informed designer to conclude that there is some functionality missing from them."

What else will make him become informed? I can't see how new browsers emulating old, bad browser behavior for this kind of things can ever be a good thing. The Quirks Modes are something else since I think all of us want to be able to read old pages.

Yes, MARQUEE is wonderfully mysterious since it's not even something you see that often today.

Removing such behaviours from browsers may help a little to inform those designers that test their pages in browsers other than IE. But I think it would do the browser's reputation more harm than good.

I'm not saying it's a *good* thing that we have to put up with scrolling text in Mozilla, or "spacer.gif" popping up in K-Meleon, just that it's understandable.

: Yes, MARQUEE is wonderfully mysterious since it's not even something you see that often today.

I think someone put it in as a joke.

BTW, I find the way in which K-Mel displays the tooltips (a couple of centimeteres down from the mouse pointer) more annoying than the fact that it does it at all. It obscures text at random.

The ALT attribute was originally intended to be, and is still intended to be, an alternative to an image. I'm not sure that anybody here disputes this. I don't think that anyone would dispute that every IMG tag should have an ALT attribute, even if this is blank. What puzzles me is why anyone would think that it's advantageous to have ALT text pop up over graphics. This may indeed be an advantage when viewing a large but dwindling minority of poorly written sites -- sites whose authors have confused ALT with TITLE -- but (for me, anyway) it would be a major irritation when viewing images that do not also have a TITLE tag. Pandy is right: there's no reason for K-Meleon to have this horribly twentieth-century misfeature, and it should indeed behave like Mozilla. (For a possibly nostalgic or anyway authentically horrible twentieth-century experience, people will still be able to fire up Netscape 4.x.)

I quite like the tool tips for alt attributes, and I don't want them removed. They don't bother me one bit. So far pandy has provided no other reason to remove them, other than the fact that he wants tool tips to go away entirely. Why exactly? Why do they bother you so much? They don't bother me, so I'm having trouble understanding this. I'm not opposed to there being a way to disable them, but you have shown no mercy to those of us who like them.

> Improvement indeed! Having every second WYSIWYG page display 'spacer.gif' all over is really neat. Not to speak of having it read it aloud to you.

Bad web developers will be bad web developers, no matter what technology you give them. If you don't like the way a page acts, you need to tell the page designer. And please name ONE browser that reads 'spacer.gif' out loud to you, there are none, you just made that up to be dramatic.

I realize what alt and title are meant for, (And since sven doesn't, I think he should know that alt="green arrow, pointing left" is not appropriate alt text.) And in theory, it would be great if we could just switch over night to something like IMG to OBJECT and ALT to TITLE, but I really don't see what the problem is here other then semantics.

You ask why should we have alt when we have title, why shouldn't we? Some people would also like to get rid of the B and the I tags, but in my opinion this is stupid. I understand there are two ways to do this, but good. It's already hard enough to get one technology implemented by everyone, we don't need to be eliminating everything.

In a perfect world CSS would have provided a display:tool-tip:

img:before {content:attr(title);display:tool-top}

But we don't have that, so I think the best solution is to have a check box that you could disable alt tool tips.

> No, that would keep less savvy authors doing this.

Pandy, alt text is a required attribute, while title is not. So, even if you remove tool tips, people would continue to supply alt text, therefore, your conclusion is not sound. Don't get me wrong, I think that alt should NOT be a required attribute, especially not if the only reason you're providing it, is to remove those [IMAGE] placeholders in opera.

> If the functinality of a site depends on tooltips being displayed there is something fundamentally wrong anyway.

You see, now you're starting to confuse me. First you say that people should use title instead of alt, now you say that no one should use tool tips altogether. Maybe you don't like them, and we should add a check box to disable them, but tool tips are not considered bad by everyone, otherwise, why is there a title attribute, and why do people keep using title? I know that I like tool tips for both alt and title.

If there are any changes, those changes should not be like what opera does with tool tips. Opera displays title attributes both as a tool tip and on the status bar, but when people add the title attribute to links, this hides the href attribute, both in the tool tips and on the status bar. The only way to find out where a link is pointing to is to copy and paste the link into another application, or a text area. This is very bad, and I tried to tell opera about it, but they still haven't changed this bad behavior. I suggest that all of you complain about it, and ask them to fix it, make sure to mention that you can't see the href where links are pointing.

I realize that you can turn off title tool tips for links, but I shouldn't have to, the href should display in the status bar. Now, if they want to display both HREF and TITLE in the status bar together, then ok, but I still need to see the address of links somewhere.


PS - Why are the headlines on this page font tags with a .PhorumTableHeader class:

[td bgcolor="#000080"][FONT class="PhorumTableHeader" color="#FFFFFF"]


And why are they mentioned twice in the CSS?

.PhorumTableHeader
{
font-family: Verdana, Arial, Clean, Helvetica, sans-serif;
font-size: 12px;
}

.PhorumTableHeader
{
font-family: Verdana, Arial, Clean, Helvetica, sans-serif;
font-size : 18px;
font-weight: bold;
}

I can't help but think that headlines should be headlines, and not font tags, or maybe the table cell could be TH tags.

Here is my solution:

1. Remove the font tag and replace it with a h3 or h4 tag,
2. place the class="PhorumTableHeader" in the TD,
3. change the bgcolor="#000080" of the TD to a lighter color for backwards compatibility with non CSS browsers, (assuming that's what you were trying to do with the font tag?) Then override the background of the TD in the CSS:

.PhorumTableHeader{background:#000080}

4. Then mark up the headings with a contextual selector:

.PhorumTableHeader h3 {color:white;margin:0%}

This will also make the page logical for user style sheets. Does K-meleon support user css or alternate style sheets yet?

pandy> Yes, MARQUEE is wonderfully mysterious since it's not even something you see that often today.

I think it was included becuse an awful lot of Cineese webpages use it.

What disturbs me the most though is that <marquee> will work even in STRICT parsing mode in Gecko. Providing support for crappy code in quiksmode is IMO ok, but not for code that is supposed to be valid 4.01 or XHTML.

Jeff Mile> You ask why should we have alt when we have title, why shouldn't we?

Alt and Title are 2 different things entirely and both are needed.
If you are refering to "why shouldn't they do the same thing" then the answer is "becuse you don't have 2 attributes to eg specify height of an image either, only 1 attribute for 1 function".

Jeff Mile> Some people would also like to get rid of the B and the I tags, but in my opinion this is stupid.

I actually tend to agree. The problem with <B> and <I> is that it can be very difficoult (especially in a non graphical browser) to determine if something is bold becuase
1) This is very important
or
2) It looks nice in a graphical browser to have this text in bold.

#1 is very important for eg a blind person to know, while the 2nd is totally irrelevant.
The problem is that at least 90% of webdevelopers don't think about this large difference between 1 & 2 and happily use <b> and <i> even when they sometimes should use <strong> or <em>.
Getting rid of those old presentational markups (which has no place beeing in HTML to begin with) would "force" webdevelopers to think about the difference and use proper tags and CSS to create "looks nice in a graphical browser" effects.

Jeff Mile> I think that alt should NOT be a required attribute

The reson it's required is to do with one of the W3C's preime goals, to create an "accessible for anyone" future web. And that has to include making webdevelopers aware of the isues involved.