Re: Dropping <input usemap="">

Hi Philip,

On Aug 16, 2007, at 6:19 AM, Philip Taylor wrote:
> Robert Burns wrote:
>>>> It doesn't submit form data. We have an <input type-'image'>  
>>>> that doesn't submit form data (unless the map is nohrefed or  
>>>> something like that). That doesn't sound like it works as  
>>>> intended to me.
>>>
>>> It does submit form data, when you click on a part that's not  
>>> already covered by the client-side image map.
>> I see I was wrong there, again based on what Lachlan had said. It  
>> does work in FireFox and Opera as the HTML 4.01 recommendation  
>> specifies.  And that means that it works when @href is not set on  
>> the |area| elements (its not just those area not covered by | 
>> area|). That is the feature we're discussing here. It cannot be  
>> done without the @usemap attribute.
>
> In Firefox/Opera, when you have an <area> with no href, clicking on  
> that area does nothing at all (unlike when you click on somewhere  
> not covered by any <area>).

Well, that's an implementation problem.

> If you wanted it to transmit the click through the area onto the  
> image button behind it, then that's no good for accessibility  
> (users without a pointing device couldn't click through the area,  
> and activating an <area> with the keyboard wouldn't be able to do  
> anything sensible since the UA would have no idea what was sensible  
> in that case), and it would be incompatible with the current  
> implementations in Firefox/Opera.

Again, those are implementation problems that could be handled in a  
much richer fashion. For keyboard access, users could tab through the  
|area| elements. As each |area| got focus it would get the focus  
outline (though the outline would match the shape of the |area|  
whatever that may be). For aural users, they already can navigate the  
|area| elements and select the appropriate one based on the @alt text.

> As far as I can tell, the only advantage is that users with  
> pointing devices could get title tooltip texts on different areas.

However, it COULD be much more than that advantage wise. By liaison  
with the CSS WG, we could encourage better CSS support for client- 
side image maps to provide richer UI experiences for users using  
those image maps. Relevant CSS properties include border, outline,  
height and width, etc.) CSS3 or beyond could add properties to add  
certain masks to the image (like enlighten to make the hovered,  
focussed or activated area become brighter).

>>> Pure client-side image maps without any server-side scripting are  
>>> already handled by <img usemap>, so <input> doesn't benefit from  
>>> supporting them too. Without server-side scripting, I can't see  
>>> how you would use <form> or <input> at all.
>> An image map could be used client-side to narrow a user's choices.  
>> Imagine an interface to select the timezone from an image of a  
>> world map. In a visual browser, as the   mouse hovers over each  
>> timezone, the area could be highlighted. Also a hover view (what  
>> some call a tooltip) could be displayed indicating the timezone  
>> such as "central standard time", or "atlantic daylight time". In  
>> an aural browser the user would pick from the different area  
>> elements by hearing the @alt text and the advisory @title text.  
>> Once the user selected a timezone, a javascript could set the UTC  
>> offset in another <input type='hidden'>. None of this requires  
>> server-side support. The server need not even know that an image  
>> or an image map is involved in this interface. The page could be  
>> served from a different server than the one the form is submitted to.
>
> If you're not using a server side, there's no point in using server- 
> side image maps, so <input usemap> is irrelevant - just use client- 
> side image maps.

I thought we were discussing client-side image maps. I hadn't said  
anything in support of server-side image maps (though they have their  
place, but I hadn't said anything  in favor of them).

> <input id="gmtoffset">
> <map name="m">
> <area shape="rect" coords="0,0,20,100" href="#" title="GMT-0100"  
> alt="GMT-1" onclick="document.getElementById('gmtoffset').value =  
> -1; return false">
> <area shape="rect" coords="20,0,40,100" href="#" title="GMT+0000"  
> alt="GMT" onclick="document.getElementById('gmtoffset').value = 0;  
> return false">
> <area shape="rect" coords="40,0,60,100" href="#" title="GMT+0100"  
> alt="GMT+1" onclick="document.getElementById('gmtoffset').value =  
> 1; return false">
> </map>
> <a><img src="worldmap.jp2" usemap="#m"></a>
>
> If you do have a server side, you can avoid the reliance on  
> scripting by doing <area ... href="selecttimezone.cgi?-0100" ...>.

However, with properly speccing the client-side image-maps we could  
also avoid scripting client-side by using <input usemap>. It may be a  
small difference, but for some authors its an obstacle. Also, the  
same could be said for <input type=image> and <input type=button> and  
<button> itself. All of those could be replaced by <img> with some  
scripting thrown in. So I don't see why we apply one standard for  
those features, but another for the <input usemap> feature. By making  
the language consistent and supporting parallel construct wherever  
possible, it makes the language more intuitive for authors to use.  
This isn't only about accessibility. Its also a matter of allowing  
more to happen on the client-side where often it makes sense to save  
round-trips to the server. Its also about lowering the bar for  
authors who can now accomplish more with fewer skills. And finally  
its also about accessibility, where providing these rich UI client- 
side features also happens to make it all more accessible. This to me  
seems like the WhatWG approach.

Take care,
Rob

Received on Thursday, 16 August 2007 12:05:30 UTC