Re: Dropping <input usemap="">

HI Philip,

On Aug 16, 2007, at 9:05 AM, Philip Taylor wrote:

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

OK. I still don't understand how you're applying this criteria, but  
that's not that important to me right now.

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

The difference between <input usemap> and <img usemap> is the same as  
the difference between <input type='image'> and <img>. Perhaps that  
sounds too much like an entrance exam analogy question,, but that's  
the best way I know how to put it. I actually have never implemented  
either of those features in a browser, so I'm not totally familiar  
with all of the intricate similarities and differences between them.  
If you were to tell me that <input type=image> is identical to <img>,  
I would say OK I believe you. If the only difference is that <input>  
can be put into a form without adding event attributes, OK, then I  
guess the differences are very minor. What would YOU say are the  
differences between THESE: <input type="image"> and <img>?

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

I guess. I still don't understand what you're saying about how these  
things behave. I did my LiveDOMVierwer example, but that's not  
telling me how the click events are handled. Firefox seems to  
basically do what I'd expect (again, I'm not sure what the click  
event is doing and of course none of the CSS works).

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

OK. that sounds like a good thing then. Perhaps we're closer to  
implementation of the feature I want than I thought.

>>> * 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?

Well, I think we'd have to specify this. Its definitely not in the  
HTML 4.01 recommendation as far as I am aware. My first stab at this  
is that it should probably be the coordinates for the shape-specific  
origin of the |area| (would the origin be appropriate like 0,0  or  
would it need to be shifted toward the center of the area). So for a  
circle it would be the x, y coordinates of the center. For a polygon,  
it would be the first x,y pair. For stacked areas, it might get more  
complicated. I'd have to think about this further to come up with a  
straight-forward solution. Basically the UA would have to find a  
coordinate that was in the area activated, but was not in any other  
area  (if no such x,y cooredinate pair existed it could just send  
null or "" instead).

Take care,
Rob

Received on Thursday, 16 August 2007 14:32:10 UTC