Re: Dropping <input usemap="">

Hi Lachlan,

On Aug 16, 2007, at 12:07 AM, Lachlan Hunt wrote:

>
> Robert Burns wrote:
>> The assumption may be wrong or it may be right. The point is, it  
>> just doesn't matter. Let's assume that all of these authors were  
>> just typing randomly and happened to type <input type='image'  
>> usemap='*'>.  Then the number of authors trying to use this HTML  
>> 4.01 feature that has not been implemented is 0%.
>
> Please try to understand that there is a significant difference  
> between trying to use a specific feature and trying to fulfil a use  
> case.
>
> [...]
>
>

The problem with your approach, Lachlan, is that you don't bother to  
understand what a feature is for or how to properly use it before  
"researching" it and dismissing it. The "research"Ian conducted is  
another case in point.

@usemap on |input| is not supposed to be used like @usemap on |img|.  
The whole point of putting it on |input| is to use it in a way unlike  
putting it on |img|. Yet you keep focussing on this misuse of |input|  
and claim that this shows that its not needed (because its redundant  
with |img| and @usemap) The example you rpovide is just another case  
in point.

When properly implemented (which hasn't happened) @usemap on |input|  
has clear use-cases. I've provided examples before. And yes authors  
jump through all sorts o hoops to implement functaionality when its  
not implemented in browsers. However, this is some fairly tough stuff  
to do in javascript. I've already raised the image slice solution and  
the problems associated with that. So yes there are some very  
horrible solutions that authors turn to because the implementations  
do not meet their needs or the vision of client-side image maps in  
the HTML 4.01 recommendation.  So why not make this easier for  
authors. Why not provide image maps where the UI in a web application  
can begin to rival the desktop (without all sorts of crazy steps).

That requires an interoperable implementation . That requires  
cooperation with the CSS WG. It requires all sorts of things, but to  
simply say authors can continue pursuing these horrible hacks they  
already have, is ridiculous. What happened to the PAVING of the  
cowpaths. Now you just want to tell them the dirt path is good enough  
for them.

> [1] http://shadow2531.com/opera/testcases/imagemaps/002.html

Your example fails to use <input usemap> in the manner it was  
intended (of course its hardly implemented correctly anyway). Your  
example demonstrates what can be done without an <input usemap>  
However, <input usemap> has other uses unrelated to <img> usemap>

This example I already provided[1] is a better example that reflects  
what client-side image maps are for. Again, it doesn't work right in  
any browser (Firefox comes the closest but it's not saying much).  
This example would be a horrible chore to reproduce with javascript.  
As I  said before it involves implementing basic browser features  
with javascript: features that should already be implemented by the  
browsers. Slices can work, but that's a tedious process that causes  
many needless trips to the server when image-maps involve no extra  
trips to the server. So there are other horrible solutions to the  
client-side image-map. Should we make that a design principle:  
solutions should be horrible to author.

Take care,
Rob

[1]: <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C% 
21DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cmap%20name%3Dm%3E%3Carea%20title 
%3D%27left-side%27%20alt%3D%27right-side%27%20shape%3Drect%20coords% 
3D0%2C0%2C100%2C100%20href%3D%3E%3C/map%3E%0A%3Cform%20action%3D.%3E% 
3Cinput%20title%3D%27left-side%27alt%3D%27left-side%27%20type%3Dimage% 
20src%3Dimage%20usemap%3D%23m%3E%3C/form%3E>

Received on Thursday, 16 August 2007 05:46:44 UTC