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

Re: Dropping <input usemap="">

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Thu, 16 Aug 2007 17:34:06 +1000
Message-ID: <46C3FDEE.9070405@lachy.id.au>
To: Robert Burns <rob@robburns.com>
CC: public-html <public-html@w3.org>

Robert Burns wrote:
> On Aug 16, 2007, at 12:07 AM, Lachlan Hunt wrote:
>> 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.

So your saying we should just include or retain a feature under the 
assumption that there is some unknown or insignificant use case, which 
is not even supported by any implementation of that feature, nor even 
described in HTML4?  That's absurd!

The problem with your approach is that you have proceeded throughout 
this entire thread without a clearly defined and justified use case, on 
the assumption that everybody else should already know what that use 
case is.

> @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|.

HTML4 did not define in any way whatsoever how <input usemap> was 
supposed to be implemented, let alone describe how it was supposed to 
fulfil some unknown use case.  That is precisely why there are no 
implementations that meet to the requirements of your purported use case.

As I stated near the beginning of this thread, it was largely rejected 
at this stage on the grounds of "no *known* use cases".  That is why I 
have repeatedly asked for *significant and convincing* use cases of form 
submission using image maps, which you have not yet presented well 
enough, beyond a few vague hypothetical examples.

> 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.

No, you misunderstand what I was looking for.  When I spent *hours* 
yesterday, meticulously going through those first 50 examples in that 
list, I was actually looking for some evidence of the hypothetical use 
case you described.

As it tuns out, only a single example even came close, and that on its 
own is hardly enough to justify the cost of designing, speccing and 
implementing, let alone continuing this rather unproductive discussion 
about a feature for client-side image map form submission.

> When properly implemented (which hasn't happened)...

Properly implemented according to whom?  There is no specification for 
it!  There's basically a DTD which says the input element has a usemap 
attribute.  That's it!

Before you can claim that it isn't properly implemented, there needs to 
a spec that defines the following:

* What's the result of activating an <area> with an href attribute.
   - Should the UA follow the hyperlink?
   - Should it ignore href for areas of input images and submit the form?

* What's the result of activating an <area> without an href attribute.
   - Should it submit the form?

* If it submits the form, what co-ordinates should be sent?  How does
   the UA calculate them?
   - If the use clicks on the area, should it send the co-ordinates of
     the mouse pointer, or the co-ordinates of the activated <area>?
   - If the user activates it with the keyboard (e.g. tabbing and
     pressing Enter or an accesskey), how does the UA calculate the
     co-ordinates to send for each shape (rect, circle and poly)?
   - Should it submit the top left corner?  The centre point?
     The first pair of co-ordinates (in the case of poly)? Any random
     co-ordinates within the area?

* What if the area doesn't actually cover any part of the image?
   - Cause no submission to occur?
   - Submit with co-ordinates calculated as if it were covering the
   - Submit some default co-ordinates, like 0,0?

* What does the nohref attribute do in this case?
   - Nothing at all, just like when an href attribute isn't provided?
   - Cause no submission to occur for that area, since HTML4 has the
     vague statement that says "this region has no action"?

* What's the result of activating a region not covered an an <area>?
   - Is that an active or inactive region?  i.e. Should it submit with
     the mouse co-ordinates or not?

I'm quite sure that isn't an exhaustive list of issues that would need 
to be defined.  But it is hardly something that is trivial to spec and 
implement, and there is simply no significant justification available at 
this stage for spending any time developing it.

> @usemap on |input| has clear use-cases. I've provided examples before.

No, you have only described hypothetical use cases.  At this stage, you 
have utterly refused to contribute any real evidence and examples that 
clearly demonstrate the significance of those use cases, and blatantly 
rejected out of hand any evidence that doesn't support your case.  That 
is not the way a productive discussion should work.

>> [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>

FYI, it's not my example.  It's the one Michael presented earlier in the 
thread.  However, you missed the whole point of it.  The point was to 
illustrate how authors could implement client-side image map form 
submission without <input usemap> which, as you know, isn't suitably 
implemented.  It is an example of something that you need to look for in 
the real world to help justify the significance of the use case you have 
in mind.

Please, before you instinctively respond and object to everything I have 
said as a matter of principle (as you seem to always do), carefully 
consider and reflect on the situation and try to look at the issue from 
different points of view.

The responses I have given you are not just intended as a way to shoot 
down your ideas, rather I've tried to describe exactly what you need to 
present that would make your case stronger.  Please take the advice, 
look for the kinds of examples I have suggested, and respond when you 
can clearly justify the significance of your use cases using your results.

Lachlan Hunt
Received on Thursday, 16 August 2007 07:34:18 UTC

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