Re: Dropping <input usemap="">

On Aug 15, 2007, at 6:18 PM, Philip Taylor wrote:

>
> 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.

I thought you were saying it doesn't work as intended in those  
browsers. I thought you said it worked the same as <img usemap>  
rather than submitting form data. If <input usemap> is exactly the  
same as <img usemap> then of course there's no reason to maintain it.  
However, my reading of the HTML 4.01 recommendation is that <input  
usemap> is supposed to submit form data (with x and y coordinates as  
well). Since no one implements that (which is what I understand you  
saying) then it has never been implemented.


>>>> 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).

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.

> 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).

Right, but the <input> combined with client-side image maps has never  
been implemented.

>> 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).

No, usemap is not combining client-side with server-side, its  
replacing server-side with client-side. If an image can be mapped  
completely client-side, then the server-side mapping is completely  
unnecessary.

> <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.

I'm not sure why you call it an accessibility "hack". Its an  
alternative way of doing image maps that is accessible (just like  
slicing up images is another alternative way to do image maps). We  
can disparage it by calling it a "hack", but it would be more helpful  
to explain what ways its not as good or more difficult than server- 
side maps. For some authors, client-side maps may be the only option  
(which is the other use-case I presented).

> 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.

What better mechanisms are being proposed. I can think of several  
alternative mechanisms, but none of them strike me necessarily  
better. Some authors may have some familiarity with image maps in  
general  (including client-side image maps). It makes sense to me  
that an author should be able to apply that knowledge to a form  
submission image, just as they do with a standard image. If we were  
getting rid of image maps in general, that would be one thing. But if  
we think image maps are useful, then client-side form- submission  
image maps have a clear use too.

A big benefit of the HTML 4.01 @usemap are that  an author can  
implement client-side image maps without any server-side scripting,  
without any knowledge of scripting at all. It can be done in pure  
HTML markup. That to me is a benefit. Slicing images can accomplish  
the same thing, but that's a lot of round-trips to the server. With  
EDGE latency where it is, I don't want that on my iPhone (I don't  
really have an iPhone, but hypothetically speaking). So what superior  
mechanisms are we talking about. For someone with no server-side  
scripting access (because of skills or privileges), there are few  
other options.

For those with server-side access, the other approach would be to use  
something like |object| or |img| with @longdesc to point to a  
separate page or document fragment that had a menu or list to select  
the same things. Taht doesn't really sound all that superior to me  
either.

Take care,
Rob

Received on Wednesday, 15 August 2007 23:40:08 UTC