W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Dropping <input usemap="">

From: Philip Taylor <philip@zaynar.demon.co.uk>
Date: Thu, 16 Aug 2007 00:18:33 +0100
Message-ID: <46C389C9.1080808@zaynar.demon.co.uk>
To: Robert Burns <rob@robburns.com>
CC: public-html <public-html@w3.org>

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
Received on Wednesday, 15 August 2007 23:18:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:11 UTC