Re: Dropping <input usemap="">

Hi Lachlan,

On Aug 15, 2007, at 4:36 AM, Lachlan Hunt wrote:

>
> Jason White wrote:
>
> Why is it useful to do <input usemap> instead of <img usemap>?

That to me is the same question of why it is useful to have <input  
type='image'> instead of just <img>. Or why is it useful to have <img  
ismap >  and so on.  If there's a use-case for that, then there's a  
use-case for the usemap case for <input>. What's telling about this,  
though is that its always the accessibility impacting question that's  
posed and not these other ones.

>> It may  not have been implemented correctly in UAs, however that  
>> can be dealt with by filing bug reports. The fact that it's not  
>> correctly implemented in UAs may also point to the reason and the  
>> solution to why it has not been widely used by authors.
>
> That may be one reason.  The other is the *lack of convincing use  
> cases!*

This is really no way to discuss a specification. You don't like  
other people's use-cases. Other people won't like your use-cases.  
This needs to be about solving problems. Unless you can layout what  
problems you think we will solve by eliminating <input type=image  
usemap= > from HTML, why are you even posing it. What real-world  
problems will this solve? To build consensus, we need to make  
arguments that others can understand and relate to. You cannot just  
dig in your heels and say "Everyone has to think of design and  
prioritize the way I want them to." That's no way to build consensus.

>> If we're going to support @usemap on IMG (and I think we should)  
>> then we should also support @usemap on INPUT. I often surprised at  
>> the lack of imagination here, but an obvious use-case for this  
>> would be to submit form data based on where a user clicks on the  
>> INPUT image. This could be used in games, it could be used to  
>> provide GUI selection of items, it could be used in all sorts of  
>> ways (if it were implemented correctly).
>
> Hypothetical use cases like that are useful for determining what to  
> look for, but are not strong enough on their own to support your  
> case.  You need to provide evidence of such use cases and clearly  
> demonstrate why usemap on input is a better solution than usemap on  
> img or any other alternative solution.

You keep throwing out the word evidence, but I have no idea what  
you're talking about. If you have some research in mind, you need to  
provide research methodology, research criteria, and so on. I'm  
already convinced we should solve any @usemap problems in a way other  
than dropping it. I don't need to find any evidence at all. If you  
need evidence, you should shoulder the burden of telling me what kind  
of evidence you need. I created a Wiki page just for that purpose.

For example, I would say that having client side input maps (to  
abbreviate), is worth having even if the browser has to supplement  
that with sever-side image maps to work around the quirks of poor  
implementation (that way the visual user can click on the input  
image, and it will send coordinates to the server, but the visually  
impaired user can activate areas in the image map to do the same). I  
don't need any further evidence for that then what I already have in  
front of me. If you have a need for evidence in mind, you should be  
specific about what you're looking for.

To get rid of this feature, I would need to be convinced that no  
other approach would work. In other words all the things listed by  
Jason would need to be exhausted first before I would consider  
eliminating these features. Its not just a matter of gathering  
together interesting but trivial unscientific statistics. What good  
is that to me? I'd say none. Its about providing solutions that work  
consistently across the language. If an author can do many of the  
things with IMG and INPUT except this one, that's just adding  
confusion and complications to the language. That's creating  
problems, not solving them.

> These are the kinds of possibilities you could look for.
>
> * Sites that use <input usemap> for legitimate use cases.

I think the fact that this is not implemented in an interoperable way  
already suggests the existence or non-existence of evidence like that  
is useless. We might as well be looking for evidence of the <element- 
I -just-made-up> is used appropriately and for legitimate use-cases.  
A poorly implemented feature from HTML 4.01 has little more  
likelihood of existing in the wild than that element.

> * Sites that use regular image maps that, when clicked, cause a  
> form to be submitted using JavaScript.  This could include cases  
> using either usemap or ismap.

We've already seen some of those cases. So what?

>
> * Sites that use image slices to construct a pseudo-image map for  
> multiple input controls, each of which perform a different function.

OK, I've seen those too. What will this tell us?

> There may be some other things you could look for as well.  This is  
> a good example for how Paving the Cowpaths works.  You don't  
> necessarily need to find the exact solution in use, just sites that  
> demonstrate the use cases.

I don't see how this issue could have anything to do with paving the  
cowpaths. We have a feature of HTML 4.01 that has been poorly  
implemented so that it is not interoperable at all. Why would you  
expect such a feature to be used by authors at all? Why would you  
jump to the conclusion that if authors don't use features that aren't  
yet implemented, that means the features shouldn't be implemented?  
The language would never change with that reasoning.

> However, the presence of such sites alone doesn't necessarily  
> support your case, since you would still need to explain why usemap  
> on input would be the superior solution to any other, taking into  
> consideration the existing solutions being used and other possible  
> solutions.

Why would I need to explain why it is the superior solution. The very  
existence of this difference betweeen <img> and <input type='image'>  
has the same redundancy that you're saying I need to explain. Except  
there is no suggestion that we get rid of <input type='image'> The  
application of principles again is wildly uneven.

> And also, you have explain why the use cases are significant enough  
> to bother spending time on, and for UAs to bother implementing.   
> This is related to the proposed Baby Steps principle that Hixie  
> added to the wiki.  In other words, it's sort of like a cost/ 
> benefit analysis to justify it.

This would be a baby step. After. HTML 4.01 was published 8 years  
ago, implementations would take another baby step (smaller than any  
the'd taken so far) to correctly implement <input type=image'  
usemap=''>. So the baby step principle is totally behind me on this  
issue.

> *Analysis of Results*
>
> This is the analysis of the research Hixie performed earlier.  I  
> manually inspected the first 50 results in the list.  I have not  
> personally inspected the rest yet, as it was very time consuming.  
> Please feel free to continue, although I expect much more of the  
> same results.

Let me try to say this another way. I do not understand why someone  
who places such importance on evidence would be the slightest  
interested in the trivial results of an unscientific statistical  
poll. Why don't you just ask some of the members of the WG, to tell  
you what they think. It should carry at least as much weight as those  
results.

If we can get financial backing for real scientific studies  
(statistical or otherwise) of these things, I'd be all for that. I  
don't know whose going to come up with the kind of money that would  
be involved, but it might be a useful evidence gathering exercise  I  
do not think lists of sites like the one you provide tell us much of  
anything about what to do with the @usemap feature.

Take care,
Rob

Received on Wednesday, 15 August 2007 10:13:23 UTC