- From: Robert Burns <rob@robburns.com>
- Date: Wed, 15 Aug 2007 05:13:03 -0500
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: Jason White <jason@jasonjgw.net>, public-html <public-html@w3.org>
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