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

Re: Dropping <input usemap="">

From: Robert Burns <rob@robburns.com>
Date: Wed, 15 Aug 2007 08:27:24 -0500
Message-Id: <EE0978C2-75A4-44C9-B740-07E1F4ED2B7B@robburns.com>
Cc: public-html <public-html@w3.org>
To: Philip Taylor <philip@zaynar.demon.co.uk>

Hi Phil,


On Aug 15, 2007, at 7:56 AM, Philip Taylor wrote:

>
> Robert Burns wrote:
>> On Aug 15, 2007, at 4:36 AM, Lachlan Hunt wrote:
>>> [...]
>>> 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.
>
> The data at <http://canvex.lazyilluminati.com/survey/2007-07-17/ 
> analyse.cgi/index> suggests that (0.8+/-0.2)% of the 4.5 million  
> pages listed on dmoz.org use <blink>. That has about the same level  
> of support as <input usemap> (it works in Netscape/Firefox but not  
> in IE) and degrades in the same way (it just gets ignored), but  
> <blink> is used two thousand times more than <input usemap> (given  
> the "0.00036%" from Hixie's data). <element-I-just-made-up> is used  
> in zero pages. The differences in the likelihoods of existing in  
> the wild are significant.
>
>
> (From the same data, <map> is on (13.2+/-0.8)% of pages, and <img  
> usemap> is on about the same number, and <img ismap> is on (1.2 
> +/-0.3)% of pages. So client-side and server-side image maps are  
> both quite common on <img>, but client-side image maps are forty  
> thousand times rarer on <input>. (Unfortunately I didn't collect  
> any data on how much <input type=image> there is).)

Thanks for the additional statistics. However, I just don't know what  
these are supposed to show. No site is going to break because their | 
blink| element didn't work. However, creating a client-side image map  
that submits form data, is not something that can sorta work in some  
browsers and not in others. Usually an author will have to find an  
alternative method for satisfying that use-case and we wouldn't  
expect to see many uses of that approach.  The element <element-I- 
just-made-up>  is more like <input type=image usemap=''> in it  
intricacies  :-).

Anyway, these statistics reflect what I would expect of an element  
that either: A) has no use; or B) has not been implemented in an  
interoperable way across browsers. If we researched this and found  
that all of the important implementations all behaved the same way  
with the <input type='image', usemap='' >, then we could probably say  
that it was more likely A: this feature has no use.  However, we know  
that B is true. So we really can't conclude much about A from the  
statistics (even if they were unbiased which I'm just going to grant  
you that for now).

As far as implementing this goes its really just a combination of  
<image usemap=''> and <input image=''>.  This is not a lot of  
implementation work to get this right. It probably just hasn't gotten  
the attention it deserves. My question would be if <input  
type='image' usemap=''> is easily dropped in favor of <img  
usemap=''>, then why isn't <input type='image'> also easily dropped  
in favor of <img>? Why aren't we discussing dropping @ismap from | 
input|? The use-cases would be the same wouldn't they be? And more  
importantly, what's so important about purging the language. Let's  
focus on the interoperability, on more consistent parsing and  
rendering and on the new semantics. What's the point of spending all  
this time trying to purge these pieces. Perhaps we could write some  
new prose a new algorithm that would clear up the interoperability  
problems with <input type='image' usemap=''> and then there's no  
reason to spend all this time researching or debating the issue.

Take care,
Rob
Received on Wednesday, 15 August 2007 13:27:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:04 GMT