Re: Dropping <input usemap="">

HI Philip,

On Aug 15, 2007, at 7:48 PM, Philip Taylor wrote:

>
> Robert Burns wrote:
>> On Aug 15, 2007, at 6:18 PM, Philip Taylor wrote:
>>> It does work as intended in Firefox and Opera [see below], and it  
>>> falls back to the basic server-side image map functionality in IE  
>>> (like how <blink> falls back to a CSS-stylable element in IE), so  
>>> people can still benefit from its intended functionality by using  
>>> it now.
>> I thought you were saying it doesn't work as intended in those  
>> browsers. I thought you said it worked the same as <img usemap>  
>> rather than submitting form data. If <input usemap> is exactly the  
>> same as <img usemap> then of course there's no reason to maintain  
>> it. However, my reading of the HTML 4.01 recommendation is that  
>> <input usemap> is supposed to submit form data (with x and y  
>> coordinates as well). Since no one implements that (which is what  
>> I understand you saying) then it has never been implemented.
>
> What is implemented (in FF and Opera) is that if you click on a  
> part of the button that is covered by an <area> from the used  
> <map>, then it acts like a link to that <area>'s href, which is the  
> same as with <img usemap>. If you click on a part of the button  
> that is not covered by any <area>, then it submits the form with x  
> and y coordinates, which is the same as with <input type=image>.  
> Try the example I gave earlier (<http://software.hixie.ch/utilities/ 
> js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A% 
> 3Cmap%20name%3Dm%3E%3Carea%20shape%3Drect%20coords%3D0%2C0%2C100% 
> 2C100%20href%3Dhttp%3A//google.com%3E%3C/map%3E%0D%0A%3Cform% 
> 20action%3D.%3E%3Cinput%20type%3Dimage%20src%3Dimage%20usemap%3D%23m 
> %3E%3C/form%3E>).
>
> That seems like the sensible thing to implement in this case, since  
> it's consistent with how the other image maps work, and so I  
> believe it is what HTML4 intended, but the HTML4 specification is  
> far too vague for me to see whether that's actually the behaviour  
> it's trying to describe (unless I'm just missing the part where it  
> says what to do in this case).

Yes, I think we're in agreement here on that. And I think that  
suggests that we're not so confused by the HTML 4 recommendation. So  
it can't be al that bad.

However, the part that's missing without the |map| and |area| is the  
part that adds accessibility. Though it doesn't seem to work in any  
browser I've tested, @title attributes on the |area|  can convey  
further information to the user about what it means to click on a  
particular region of the image (try that with server-side maps). Also  
an aural browser user can submit from the |area| element by reading  
@title and @alt attribute values. Again, this cannot be accomplished  
with server-side image  maps and it cannot be accomplished by simply  
using  <input type='image'> without @usemap.

>
>> It doesn't submit form data. We have an <input type-'image'> that  
>> doesn't submit form data (unless the map is nohrefed or something  
>> like that). That doesn't sound like it works as intended to me.
>
> It does submit form data, when you click on a part that's not  
> already covered by the client-side image map.

I see I was wrong there, again based on what Lachlan had said. It  
does work in FireFox and Opera as the HTML 4.01 recommendation  
specifies.  And that means that it works when @href is not set on the  
|area| elements (its not just those area not covered by |area|). That  
is the feature we're discussing here. It cannot be done without the  
@usemap attribute.

>> I'm not sure why you call it an accessibility "hack".
>
> Because (as I understand it) the HTML4 designers started with a non- 
> accessible feature (server-side image maps via <input type=image>),  
> and then realised they ought to make it accessible, so they added  
> on a couple of sentences to include the feature <input usemap>,  
> without describing how it should actually work and seemingly  
> without deep design thought - it's just a small imprecise fix to  
> plug a perceived hole.

I see it as a very elegant solution to a problem, Any other way of  
accomplishing this result seems needlessly complicated. It gets into  
an area of javascripting where you're basically implementing browser  
features in javascript

> We now have a decade more experience, and the ability to look at  
> how HTML has been used in that time, and new technology to help  
> with various use cases, so we can have a better perspective on  
> whether that perceived hole is a real one that is worth fixing  
> properly for the first time.

Except no one is offering a suggestion for a feature that  
accomplishes the same result.

>> if we think image maps are useful, then client-side form-  
>> submission image maps have a clear use too.
>
> <input usemap> doesn't do a client-side form-submission image map -  
> I assume you mean that clicking on an <area> would submit the form,  
> ignoring the area's href, sending the x,y coordinates of the top- 
> left corner of the bounding box of the area's shape, or something  
> like that? If you wanted that, it would be an entirely new feature  
> that's incompatible with how <input usemap> is currently  
> implemented and used.

No, its the same coordinates it currently sends. However, the image  
map provides advisory information through @alt and @title that cannot  
be easily accomplished otherwise (again, if this were implemented  
correctly, which it's not)

>> 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.
>
> Pure client-side image maps without any server-side scripting are  
> already handled by <img usemap>, so <input> doesn't benefit from  
> supporting them too. Without server-side scripting, I can't see how  
> you would use <form> or <input> at all.

An image map could be used client-side to narrow a user's choices.  
Imagine an interface to select the timezone from an image of a world  
map. In a visual browser, as the   mouse hovers over each timezone,  
the area could be highlighted. Also a hover view (what some call a  
tooltip) could be displayed indicating the timezone such as "central  
standard time", or "atlantic daylight time". In an aural browser the  
user would pick from the different area elements by hearing the @alt  
text and the advisory @title text. Once the user selected a timezone,  
a javascript could set the UTC offset in another <input  
type='hidden'>. None of this requires server-side support. The server  
need not even know that an image or an image map is involved in this  
interface. The page could be served from a different server than the  
one the form is submitted to.

Once the user selects a timezone, a whole different group of choices  
could be presented to the user (based on that timezone). None of this  
requires any round-trip to the server. It also provides a richer user  
interface that would be hard to replicate with javascript  
(prohibitively so for many authors who might wan to use this).

Again, this isn't implemented inn an interoperable way across UAs, so  
authors have to turn to other means to accomplish this (or just give  
up on it). However, if it were implemented correctly across UAs, it  
would certainly be a much nicer user and authoring environment than  
anything I can think of or that is being proposed now.

Take care,
Rob

Received on Thursday, 16 August 2007 01:24:59 UTC