Re: Dropping <input usemap="">

Robert Burns wrote:
> The other Phillip Taylor already made this point, but I want to clarify. 
> Providing |blink| and some CSS will work interoperably.  If the browser 
> doesn't support |blink| natively, the CSS can provide a similarly 
> obnoxious visual effect. If <input type='image' usmap> doesn't work as 
> intended, then there's no point in using it at all.

It does work as intended in Firefox and Opera [see below], and it falls 
back to the basic server-side image map functionality in IE (like how 
<blink> falls back to a CSS-stylable element in IE), so people can still 
benefit from its intended functionality by using it now.

>>> However, creating a client-side image map that submits form data, is 
>>> not something that can sorta work in some browsers and not in others.
>>
>> I may be misunderstanding you, but it's never possible to create 
>> client-side image maps that submit form data in any browser - form 
>> submission only happens as part of server-side image maps.
> 
> No, you're understanding me here. In other words, the  <input 
> type='image' usmap> feature works in 0% of implementations (according to 
> your research) so why would we expect to find authors using it?

Sorry, I may have been unclear: it does work as intended in Firefox (but 
only with type=image, which I think is a bug according to HTML4) and in 
Opera (on other input types too).

By "it's never possible to create client-side image maps that submit 
form data in any browser", I meant you can still do <input type=image 
usemap=#m> which will create a client-side image map on top of a 
server-side image map button, but the client-side component of it will 
never submit form data (since it's just plain <area href> links instead).

> And its not clear to me that you're saying that you don't see a use-case 
> for image maps or input image maps. It sounds like you're saying that 
> server-side input image maps are already provided, so why provide 
> client-side image maps. Its not clear which thing your asking for 
> use-cases for: A) client-side; or B) image maps. If its B, I've provided 
> some possible use-cases (Laclan dismisses them as hypothetical). Some of 
> the research has uncovered other use-cases (though those use-cases are 
> all implemented ultimately through server-side  support).

Client-side image maps are already provided (by <a href><img 
usemap></a>), and server-side image maps are already provided (by <img 
ismap> and <input type=image>). The issue is with combining a 
client-side image map on top of a server-side image map (which is what 
<input type=image usemap> does).

<input usemap> appears to be an accessibility hack that was added 
because server-side image maps are inherently not accessible. You can 
get much better accessibility by not using server-side image maps at all 
- e.g. by using a normal client-side image map (suggested in 
<http://www.w3.org/TR/WCAG10-HTML-TECHS/#client-vs-server-side>), or 
providing multiple form submission buttons or using scripting (suggested 
in <http://www.w3.org/TR/html4/interact/forms.html#h-17.4.1>), etc.

If the use cases for <input usemap> can be handled by better mechanisms 
that aren't based around something inherently inaccessible, and if UA 
support for <input usemap> is not required for supporting existing 
content, then there is no value in having the specification include the 
accessibility hack and it is better to promote the more fundamentally 
accessible alternatives.

-- 
Philip Taylor
philip@zaynar.demon.co.uk

Received on Wednesday, 15 August 2007 23:18:42 UTC