W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Dropping <input usemap="">

From: Robert Burns <rob@robburns.com>
Date: Fri, 17 Aug 2007 01:58:12 -0500
Message-Id: <CEB41D33-5FE4-4056-AE65-1BC0B9D5EE59@robburns.com>
Cc: public-html <public-html@w3.org>
To: Ian J.Wessman <w3@iria.net>

On Aug 16, 2007, at 8:13 PM, Ian J. Wessman wrote:
> I completely agree that new CSS properties for <area> tags can be  
> of great benefit if used properly. My comment was solely meant to  
> deal with the reality of separate working groups within the W3C.  
> The concept of <area> styling should be pursued either by or with  
> the CSS WG.

I'm in 100% agreement with you there. Its something to push the CSS  
WG to address. The only thing  would add is that its worth keep those  
presentation issues in mind as we consider semantic features.

Also, on the issue of the precise image map behavior we need to  
specify, I think much of what we specify should be closely related to  
<img usemap>, only diverging where it makes sense for <input usemap>  
to diverge. Also as an <input> element it should behave mostly the  
way <input type='image' > behaves except for where it adds image map  
features. In particular that means: 1) deciding how areas with @herf  
set should be treated (as a hybrid input/img or as a document error);  
2) creating an algorithm for non-pointing device area activation; and 3)

I looked into some differences between <img> and <input type-'img' >:  
in HTML 4.01. Here's what I found:

   For some reason, HTML 4.01 does not allow <button>,<img usemap></ 
button>. It might be worthwhile to research what they were thinking  
there (unless someone readily knows)
   Many of the event attribute differences seem to be erased by  
HTML5's globalization of many event attributes
   other than for form submission, <img ussemap> appear to be a  
substitute for <input usemap>. For form submission, it may help to  
pass the area ID tot he server as a property of the input (this  
relieves the author from needing to interpret coordinates server-side  
when the work has already been done client-side). In this sense the  
<input type-image usemap> -> map > area behaves similarly to a <input  
type=submit> -> select > option, except where the selection and the  
submit happen together.

So outside of forms, <img usemap> would be very similar in function  
to  <input type-'image' usemap>, just as <img> is similar to <input  
type='image'>. To see if a client-side image map was being used  
correctly, we would want to search for not only areas that had href,  
but also areas that had mouse-event attributes set (or those who had  
mouse-event attributes set or @href set through DOM calls). Within  
forms, it would be useful to submit the area ID to the server as part  
of the form data (I'm not sure if that happens now, but it should).  
Again this helps the author avoid the ned to produce a server-side  
interpretation of coordinates in addition to producing a client-side  
interpretation of coordinates. The client-side interpretation of  
coordinates through client-side image maps provides a much richer UI  
experience as well as providing better accessibility.

Take care,
Received on Friday, 17 August 2007 06:58:23 UTC

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