Re: Dropping <input usemap="">

Hi Philip,

On Aug 16, 2007, at 7:54 AM, Philip Taylor wrote:
> Robert Burns wrote:
>>> If you're not using a server side, there's no point in using  
>>> server-side image maps, so <input usemap> is irrelevant - just  
>>> use client-side image maps.
>> I thought we were discussing client-side image maps. I hadn't said  
>> anything in support of server-side image maps (though they have  
>> their place, but I hadn't said anything  in favor of them).
>
> My understanding of this thread is that we were discussing <input  
> usemap>, as it says in the subject line; and the whole point of  
> <input usemap> is that it acts like a server-side image map as well  
> as a client-side image map. When you only want one or the other,  
> you can use <input type=image> (server-side) or <img ismap> (server- 
> side) or <img usemap> (client-side).

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.

>>> If you wanted it to transmit the click through the area onto the  
>>> image button behind it, then that's no good for accessibility  
>>> (users without a pointing device couldn't click through the area,  
>>> and activating an <area> with the keyboard wouldn't be able to do  
>>> anything sensible since the UA would have no idea what was  
>>> sensible in that case), and it would be incompatible with the  
>>> current implementations in Firefox/Opera.
>> Again, those are implementation problems that could be handled in  
>> a much richer fashion. For keyboard access, users could tab  
>> through the |area| elements. As each |area| got focus it would get  
>> the focus outline (though the outline would match the shape of the  
>> |area| whatever that may be). For aural users, they already can  
>> navigate the |area| elements and select the appropriate one based  
>> on the @alt text.
>
> <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>. However, to  
answer your questions:

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

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

>> However, it COULD be much more than that advantage wise. By  
>> liaison with the CSS WG, we could encourage better CSS support for  
>> client-side image maps to provide richer UI experiences for users  
>> using those image maps. Relevant CSS properties include border,  
>> outline, height and width, etc.) CSS3 or beyond could add  
>> properties to add certain masks to the image (like enlighten to  
>> make the hovered, focussed or activated area become brighter).
>
> 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.

Yes, it should apply to all image maps. However, image maps are a  
particular HTML construct. Hence they call for participation between  
the two groups. Our charter also calls for us to work with the CSS WG  
when appropriate. We shouldn't departmentalize things to the extent  
that we don't find the right solution in the right place.

> (I would expect it's not something that would work easily in CSS,  
> since CSS thinks everything is a box whereas <area>s can be circles  
> and polygons instead. If you only want styled boxes, you can use  
> absolutely-positioned <div>s instead of <map>/<area>s and then it  
> already works. But in any case, the styling of image maps sounds  
> like a CSS issue and not HTML.)

Yes, CSS thinks of things as boxes. However, a box doesn't have to be  
a rectangle. The CSS box model has margins, borders, outlines,  
paddings, and backgrounds. There's no reason to think those same  
concepts don't apply to polygons and circles.  DIVs wouldn't work  
specifically because they have to be rectangles. CSS is already  
expanding into other non-rectangular realms with SVG styling.

The point though is that we should think about client-side image maps  
as a richer UI experience. It certainly isn't specified thoroughly  
enough in HTML 4.01 and CSS sorta missed the whole issue in its  
development. However, if we address those issues, then we have some  
richer UI controls without too much effort ("baby steps" or  
"evolution instead of revolution").

Take care,
Rob

Received on Thursday, 16 August 2007 13:19:35 UTC