- From: Philip Taylor <philip@zaynar.demon.co.uk>
- Date: Thu, 16 Aug 2007 00:18:33 +0100
- 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 philip@zaynar.demon.co.uk
Received on Wednesday, 15 August 2007 23:18:42 UTC