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 15:05:21 +0100
Message-ID: <46C459A1.8090604@zaynar.demon.co.uk>
To: Robert Burns <rob@robburns.com>
CC: public-html <public-html@w3.org>

Robert Burns wrote:
> Yes, the thread is about <input usemap> However, no <input usemap> does 
> not necessarily act like a server-side as well as a client-side image 
> map. It act like a client-side image-map first. The fact that it can 
> interact with a server-side image map is just another feature it has. 
> There's no reason to assume that it does or will in every situation. 
> Yes, and as I said before there's some overlap even between <input 
> type='button'> and <button> and <input type='image'> and <img>. So why 
> the proposal to change the draft only to remove <input usemap>? Though 
> they over lap, they each have their specific fortes.

Most of those features are being used significantly frequently, so a 
decent HTML UA has to support the features in order to support existing 
content. But UAs don't have to support <input usemap>, since few sites 
use it and those few sites are designed to still work correctly in IE 
where <input usemap> is not supported; and examples were given earlier 
of a few sites that actually work better when <input usemap> is *not* 
supported. Support Existing Content applies strongly to most of the 
features but not to <input usemap>.

>> <map name="m">
>>   <area shape="circle" coords="100,100,50" title="Area 1" alt="Area 1 
>> (circular, central)"> <!-- no href -->
>> </map>
>> <form action="submit.cgi">
>>   <input type="image" src="200x200.png" usemap="#m">
>> </form>
> First, I want to underscore that this doesn't have to be a part of 
> <form>, because that seems to be tripping up our understanding each 
> other. <input> can be used independently of <form>.

If it's not in a <form>, it can't do form submission, so how is it any 
different to <img usemap>?

>> What are you suggesting should happen:
>> * when you click on a part of the <input> that is outside the circle?
> Basically it would behave the same as <input type=image> with no usemap. 
> Except in the case of a form, I would think the submit would not happen. 

So it would do nothing, except generate 'click' events? (i.e. the same 
as an <img usemap>, in parts not covered by an <area>, and incompatible 
with how <input usemap> currently behaves in IE/Safari/Firefox/Opera)

> If it were being handled locally, it would make sense to trigger the 
> events. Perhaps the DOM could support an introspection call to ask the 
> event what |area| (perhaps by ID) called the event (in this case null).

The event.target property in a 'click' event handler on the <map> 
already points to the <area>.

>> * when you click on a part of the <input> that is inside the circle?
>> * when you select the circle <area> using a keyboard (or something 
>> equivalent) and activate it?
> When moving over the area (i.e., the frame, in this case a circle, 
> generated by the area), the appropriate events would be triggered; hover 
> views /tooltips would be diplayed, CSS would be applied, and upon click 
> the click event would be handled just like for <input type='image'>. The 
> same thing would happen for selecting the area through keyboard focus. 
> The same events would be triggered (the form would be submitted).

When a normal <input type=image> is clicked on, it adds 'x' and 'y' 
values to the form submission (which is the reason for using <input 
type=image> instead of <button><img></button>). If the form is submitted 
when activating an <area> instead (by clicking or by keyboarding), how 
would 'x' and 'y' be handled?

Philip Taylor
Received on Thursday, 16 August 2007 14:05:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC