Re: Dropping <input usemap="">

Hi Ian,

I agree with the overall spirit of your message here. I also agree  
with many of the fine points. On this issue, I disagree however:

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

That all depends on how you define functionality. As part of good UI  
(which is what we're talking about here), CSS can certainly improve  
the user experience. It can even make using the <input usemap> more  
accessible. The types of effects I described where authors use the  
'outline', 'border', 'height' or 'width' properties to change the  
area upon focus, or hover: those certainly improve the user- 
experience and can be very functional (imagine a height and width  
properties ont he area of 105% where on hover the area temporarily  
bulges out of its bounds). As I also said before, I could see having  
new CSS3 or CSS4 properties that allow the area of the image to be  
mutated by an image filter or some other effect upon focus, hover,  
activate and so on. So while it may not change the functionality of  
the image map after activation, it certainly effect functionality  
leading up to activation.

I neglected to answer many of Lachlan's questions because I felt the  
answers should depend upon several factors: 1) how <image usemap>  
behaves today in the big browsers; 2) how <input usemap>  behaves  
today in the big browsers; 3) what would make sense in forwarding the  
analogy between <input usemap> and <img usemap>.; and 4) what  
behavior would get us a rich UI experience. So having said that, many  
of the answers you give sound good to me. I'll elaborate more below.

On Aug 16, 2007, at 3:59 PM, Ian J. Wessman wrote:

> *Note: The following is meant as a thought starter, and perhaps can  
> 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

That would depend on whether we want to treat that as an authoring  
error or allow a sort of hybrid <input usemap> and <img usemap>,  
where the existence of @href implies an <img usemap> kind of area.  
Note that the research Ian did on this looked for only those areas  
with @href, so it was looking for documents where the author used  
<input usemap> but was seeking <img usemap> behavior.

>>   - Should it ignore href for areas of input images and submit the  
>> form?
> Yes, but form submission associated with <input usemap> is another  
> issue.

Based on this hybrid use, it might ignore the form and just follow  
the href. Areas without href would be for the form submission or  
<input> handling without a form. Those areas with href would be  
treated more like <img usemap>. If we went with the other approach  
and treated this as a document error,, we would simply ignore those  
clicks or submit the form (whichever we decide is the best error- 
handling there).

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

Unless its not part of  form and then its just handled however this  
input is setup to handle activate() events.

>>   - Should it submit the form?
> In my preference, not by itself.

It depends on what we decide.

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

It should calculate the coordinates just as in any image map: the  
coordinates in the map (I believe that's an origin 0,0 in the upper  
left corner of the image).

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

The mouse pointer just as in <img usemap>

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

Philip asked this question to and I took a first shot at answering  
it. I think the origin coordinates of the area would be sufficient,  
except in the case of stacked areas. Then we would need an algorithm  
to find coordinates in the activated area that were not also in the  
other stacked areas.

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

Those solutions could work too, again except for stacked areas.  
Obviously the author has shown through the construction of the map  
and the specification of areas, what coordinate differences matter.  
If a user selects an area, then any coordinate in that area is  
sufficient, we just need to pick a coordinate algorithm.

>>
>> * What if the area doesn't actually cover any part of the image?
>>   - Cause no submission to occur?
> Correct.

I would think we might go ahead and submit anyway. We would probably  
want to match the behavior for <img usemap> in this case and examine  
some existing UAs on that. If we decide this is worthwhile, I could  
add some research tasks to the wiki (we would need to test some AT  
UAs on this.

>>   - Submit with co-ordinates calculated as if it were covering the
>>     image?
> Unknown.

They could be negative of coordinates clearly outside the bounds of  
the image, coordinates. We could provide normative or non-normative  
guidance to client-side and server-side handlers to let them know  
this is a possibility to check for  (if its important).

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

If we go with the hybrid input/img map approach,  I think we'd want  
to treat that like another <img usemap> kind of area. If we treat as  
an error, then its either do nothing or submit the form. BTW, does  
HTML5 keep nohref?

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

Received on Friday, 17 August 2007 00:47:57 UTC