Re: Dropping <input usemap="">

provide a way to rethink the proposed problem. Apologies in advance  
for its length and late arrival to the discussion.

Lachlan Hunt wrote:
> Submitting the form with a specific set of co-ordinates would be  
> the only logical reason for wanting a client side image map on an  
> input control designed for form submission.  If you want hyperlink  
> image map, use img.

Robert Burns wrote:
> 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.

With the specific exception of buttons and file selection, as I see  
it the intended purpose of each and every <input> element is to  
provide a value, whether for a <form> or not.

As for image maps, their utility lies in being able to apply  
information to a 2D space, in practice almost always an image.

Which is why I don't entirely understand why <input usemap> must  
always result in a form submission action. I think that such an  
assumption (that the last possible piece of information I seek to  
select in a form will be from the image map) is somewhat dangerous.

If a user wishes to select a particular time zone from a map (to use  
part of Robert's example use case), in a form that is collecting  
other pieces of information about that user, then I contend that it  
is the @value of the <area> that is of importance.

Example HTML fragment:

<map name="m">
   <area shape="poly" coords="100,0,120,0,120,200,100,200"  
title="PDT" alt="Pacific Daylight Time" value="-7"> <!-- no href, but  
instead a *value* -->
   <area shape="poly" coords="120,0,140,0,140,200,120,200"  
title="MDT" alt="Mountain Daylight Time" value="-6">
   <area shape="poly" coords="140,0,160,0,160,200,120,200"  
title="CDT" alt="Central Daylight Time" value="-5">
</map>
<form action="submit.cgi">
   <input type="image" name="GMT-offset" src="worldmap.png" usemap="#m">
  <input type="text" name="name-last" />
  <input type="text" name="name-first" />
</form>

I can easily imagine this being of great use for stock quotes,  
charts, or anything involving a terrestrial map. When extended with  
JavaScript, its utility would even spread to games.

I believe the accessibility benefits to this approach are obvious.  
Those users that have precise pointing devices such as mice get a  
relatively rich UI to work with. Those with screenreaders are  
presented with a list of the <area> elements, and can choose 'Pacific  
Daylight Time' for themselves.

The 'cowpath' to be 'paved' is one in which we won't find traditional  
implementations of this using <input usemap> because everyone who has  
been seeking this functionality has used either JavaScript or Flash  
to achieve a similar result.

Such a drastic redefinition would of course have its drawbacks,  
including regression issues for those browsers that expect to submit  
the form immediately.

For completeness, I'll try to answer Lachlan's six questions in  
relation to this idea:

> * What's the result of activating an <area> with an href attribute.
>   - Should the UA follow the hyperlink?
No
>   - Should it ignore href for areas of input images and submit the  
> form?
Yes, but form submission associated with <input usemap> is another  
issue.
>
> * What's the result of activating an <area> without an href attribute.
Its own internal value is updated, and that value would be sent along  
with all the other form data upon submission.
>   - Should it submit the form?
In my preference, not by itself.
>
> * If it submits the form, what co-ordinates should be sent?  How does
>   the UA calculate them?
In this case, it's not about co-ordinates. Though I suppose that they  
could be included in the form submission for exhaustive completeness.
>   - If the use clicks on the area, should it send the co-ordinates of
>     the mouse pointer, or the co-ordinates of the activated <area>?
>   - If the user activates it with the keyboard (e.g. tabbing and
>     pressing Enter or an accesskey), how does the UA calculate the
>     co-ordinates to send for each shape (rect, circle and poly)?
>   - Should it submit the top left corner?  The centre point?
>     The first pair of co-ordinates (in the case of poly)? Any random
>     co-ordinates within the area?
>
> * What if the area doesn't actually cover any part of the image?
>   - Cause no submission to occur?
Correct.
>   - Submit with co-ordinates calculated as if it were covering the
>     image?
Unknown.
>   - Submit some default co-ordinates, like 0,0?
Unknown.
>
> * What does the nohref attribute do in this case?
>   - Nothing at all, just like when an href attribute isn't provided?
Could provide an alternate method of informing the browser that the  
<input> in question is meant to be used for its <area>'s @value, and  
that the form shouldn't be immediately submitted.
>   - Cause no submission to occur for that area, since HTML4 has the
>     vague statement that says "this region has no action"?
Yes
>
> * What's the result of activating a region not covered an an <area>?
>   - Is that an active or inactive region?  i.e. Should it submit with
>     the mouse co-ordinates or not?
In my preference, no submission.


-Ian J. Wessman



Philip Taylor wrote:
> That doesn't seem relevant to the discussion about <input usemap> -  
> it just applies to normal client-side image maps via <img usemap>.  
> It may be nice if you could style <area>s, but I think that's  
> solely CSS and is unrelated to the HTML WG.

BTW, I agree with Philip's comment that CSS styling of <area> is  
definitely separate from this issue. While styling an <area> would be  
at least fun and at most useful, it doesn't change the functionality  
of an image map.




On Aug 16, 2007, at 8:34 AM, Robert Burns wrote:

>
>
> On Aug 16, 2007, at 10:09 AM, Philip Taylor wrote:
>
>> Robert Burns wrote:
>>> The difference between <input usemap> and <img usemap> is the  
>>> same as the difference between <input type='image'> and <img>. [...]
>>> What would YOU say are the differences between THESE: <input  
>>> type="image"> and <img>?
>>
>> When you click on an <img>, nothing happens - it's just a non- 
>> interactive image. When you click on an <input type=image>, the  
>> input's form is submitted with the mouse coordinates added as 'x'  
>> and 'y' - it's an image and a server-side image map and a form- 
>> submission button.
>
> But an <input> has uses outside of forms. What about the difference  
> between an <img>  and <input> without a <dorm>. Then they both can  
> capture mousse events right? Can they both respond to click events?  
> Are they basically the same when the <input> is not in a form?
>
>> <input type=image> is closer to <a href><img ismap></a> - in that  
>> case, both are server-side image maps, and the difference is that  
>> <img ismap> does a GET request with just the x and y arguments,  
>> while <input type=image> does a form submission with all the  
>> form's other input values in addition to the new x and y.
>
> OK, that makes sense. However, without the form, are there no  
> differences between the two? I imagine, a <input type='imate'> can  
> also be associated with a label even though <img> cannot. Are there  
> any other differences? Are there extra events automatically  
> associated with a click() or an activate() event on an <input  
> type='image'> compared to an <img>?
>
>> So the differences with <img ismap> are "one can only do GET" and  
>> "one submits all the form's other input values too", and I can't  
>> see any way for those differences to apply to client-side image  
>> maps (i.e. usemap) since client-side image maps are never  
>> associated with forms.
>
> However, client-side image maps could be associated with forms if  
> HTML5 specified the use of <input usemap> more fully.. Don't Opera  
> and Firefox already support client-side image maps with forms using  
> <input usemap>?
>
> Take care,
> Rob
>

Received on Friday, 17 August 2007 16:59:11 UTC