Re: ToolTips: bug or feature?

On Tue, 31 Jul 2007 03:38:24 +0200, Jon Barnett <jonbarnett@gmail.com>  
wrote:

> On 7/30/07, Gregory J. Rosmaita <oedipus@hicom.net> wrote:
>>
>> aloha, chaaals!
>>
>> let me reiterate my original proposition, which is archived at:
>> http://lists.w3.org/Archives/Public/public-html/2007Jul/1135.html
>
> If I'm understanding correctly, your main point in this discussion is
> that MSIE should be free to present @alt as a tooltip if it chooses.
> You've iterated this point a few times now.

Along with Gregory, I believe that MSIE should be able to do so. I think  
we should recommend that it does not, without forbidding it.

Let's go through Ian's (actually it seems the strongest are dbaron's)  
points...

1. The spec doesn't say that it should.

Irrelevant. We are rewriting the spec, so it can say whatever is the best  
thing to do.

3. Most major browsers don't do it. (In fact only WinIE does.)

This means that most desktop browsers in use today *do* do it. I happen to  
think that isn't a good enough reason to keep doing it, but I think this  
point is self-defeating.

The rest of the reasons given make a very limited assumption - that there  
is one way to present a tool tip and no way to distinguish different types  
of tooltip, and are valid within that limited scope. Given that...

2. Doing so encourages authors to treat the "alt" attribute as a
    tooltip attribute, instead of an image replacement attribute, which
    hurts accessibility.

8. Some companies have been discouraged from using "alt" attributes on
    their images because they don't want them to appear as tooltips.

These are essentially the same problem, and only arise where the default  
is to make the two indistinguishable. They are however very sound  
arguments.

4. Doing so causes the title attribute in constructs such as the
    following to be overriden:

    <p>
     <a href="http://validator.w3.org/check/referer"
        title="Validate this page using the W3C Validator">
      <img src="icons/valid-xhtml10" alt="Valid XHTML 1.0!">
     </a>
    </p>

This relies on the specifically limited scope. It is not rocket science to  
provide a tooltip that has various pieces of information in it. But this  
is the strongest argument of the lot.

5. Users that need this feature can get it using extensions.

Huh? Why not put it into the browser? Recently, Google managed to use  
Firefox' extension mechanism to expose a huge security hole for MITM  
attacks - something that doesn't happen in the same way with inbuilt  
functionality. And Google try to do the right thing.

Relying on extensions increases the amount you ask users to trust others  
on the web, yet we still have no really good mechanism for normal users to  
understand whether they should do so. Secunia advisories (and the like)  
are not something that my Mum (quite a tech-savvy user, who introduced the  
Web to thousands of Australian schools) even understands...

6. Authors who need this feature should use the title attribute.

This is a mistake actually. Tooltips only appear in limited contexts - not  
necessarily on mobile browsers, people turn them off, etc. For better or  
for worse, authors cannot rely on tooltips appearing except by going to  
the same sort of lengths people currently do for fly-out / dropdown menus  
- i.e. build a fallback for them.

7. Extremely few pages are adversely affected by not doing this.

In accessibility, this argument carries very little weight. For a group  
who are used to being unable to do everyday things like shopping or paying  
taxes in the way one expects, you measure and treasure the successes  
rather than accepting that just because a lot of things fail, you might as  
well assume everything will and not worry about supporting a solution that  
has limited scope. (This is not to say that you should not look for a  
better way, but that killing off the relatively small handful of things  
that work now, in exchange for some hope for the future, a priori gives  
poor outcomes...)

> Instead, I suggest precisely the opposite.  HTML 5 should explicitly
> forbid @alt from being displayed as a tooltip*.  Also, @alt SHOULD not
> be presented to the user in any way by default when an image is being
> displayed - in the same manner that a UA doesn't display the contents
> of <object> if the media is being displayed.  Any other behavior
> encourages misuse of alternate content by encouraging authors to use
> @alt as supplemental, not alternate, content.

I agree that we should say 'user agents SHOULD NOT present alt and title  
in a way that makes it impossible to distinguish them'. Anything more is,  
I think, overly restrictive (and we would ignore it in practice). Anything  
less is avoiding the problem.

> * There is one exception to this...

Actually there are several. But one is enough to make me think we should  
clarify the reasoning, make the recommendation, and be done. (While we are  
at it we could remove the statement that title can be a description, or  
edit it to make sense, but that is already another thread).

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com    Catch up: Speed Dial   http://opera.com

Received on Tuesday, 31 July 2007 08:31:35 UTC