Re: Dropping <input usemap="">

On Aug 15, 2007, at 10:14 AM, Philip Taylor wrote:

>
> Robert Burns wrote:
>> 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.
>
> They will still break, though to a much more limited extent, since  
> IE users won't get the optimal viewing experience that the author  
> intended and may miss out on the intended emphasis of some parts of  
> the page - the numbers aren't directly comparable with the numbers  
> for features that break to a less limited extent, but they still  
> give some indication that many people are happy to use features  
> that are not interoperable and are not supported by the majority  
> browser.

The other Phillip Taylor already made this point, but I want to  
clarify. Providing |blink| and some CSS will work interoperably.  If  
the browser doesn't support |blink| natively, the CSS can provide a  
similarly obnoxious visual effect. If <input type='image' usmap>  
doesn't work as intended, then there's no point in using it at all.  
Again, since that is the case my hypothesis would be that we would  
see  <input type='image' usmap> — due to this reason — 0%. The fact  
that we're finding some use indicates that authors are making some  
heroic attempt to get this to work when its just not going to happen  
with current implementations.

>> 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.
>
> I may be misunderstanding you, but it's never possible to create  
> client-side image maps that submit form data in any browser - form  
> submission only happens as part of server-side image maps.

No, you're understanding me here. In other words, the  <input  
type='image' usmap> feature works in 0% of implementations (according  
to your research) so why would we expect to find authors using it?

> When they are mixed, like in <http://software.hixie.ch/utilities/js/ 
> live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Cmap 
> %20name%3Dm%3E%3Carea%20shape%3Drect%20coords%3D0%2C0%2C100%2C100% 
> 20href%3Dhttp%3A//google.com%3E%3C/map%3E%0D%0A%3Cform%20action%3D.% 
> 3E%3Cinput%20type%3Dimage%20src%3Dimage%20usemap%3D%23m%3E%3C/form%3E>
> in Firefox and Opera, the left half of the image (under an <area>)  
> is just a plain client-side image-map link, and the right half (not  
> under any <area>) is a server-side image-map form-submission button.
>
> In IE, the client-side image-map will be ignored and the whole of  
> the image will act as the server-side image-map form-submission  
> button. So you can still use <input usemap> without breaking in IE,  
> if you make your server-side code redirect the user as appropriate.  
> But even though you can easily make it work, the collected data  
> suggests that almost nobody does that.

Except for someone with a visual impairment. The client-side image- 
map is the only way (if it were implemented correctly) to access the  
web application's purpose.

>> 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>?
>
> It would have to be in favour of something like <button  
> style="border: none; background: transparent"><img ...></button> to  
> get the form-submission effect. It wouldn't be able to do the form- 
> submission-with-x-and-y-coordinates effect at all. I have no idea  
> how much people rely on the latter effect - it would be useful to  
> find out how it's used.

It might be useful to find that out.

>
>> Why aren't we discussing dropping @ismap from |input|?
>
> That attribute has been dropped already - <input type=image> always  
> submits the x and y values, regardless of whether you specify  
> ismap. (That matches what IE/FF/Opera (and probably Safari) do.)

But as you say below the coordinates are sent by default. So there is  
still server-side image map support which is what I was meant (not  
simply @ismap). If there's no use-case for image-map form submission,  
why do browsers (or why should browsers) send coordinates on a  
clicked image, input, or button?

>> 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.
>
> Interoperability and consistency can be achieved less expensively  
> by removing a feature than by specifying it, implementing it,  
> testing it, describing it in tutorials and books, etc. <input  
> usemap> would have a similar cost to an entirely new feature, since  
> there is no adequate specification of its current behaviour (HTML4  
> says almost nothing, and isn't even consistent about whether it's  
> specified or not [1]) and it is not yet widely implemented or  
> documented. The cost has to be balanced against the benefits, and  
> it looks like people have not seen a convincing demonstration that  
> the benefits are sufficient.

Some people. There's only a handful of us that have weighed in here  
on this issue. And they've weighed in on both sides of the issue.  
Sometimes I get the feeling those talking about costs here do not  
value they're own time at all, since we seem to argue endlessly over  
issues to prevent someone' incurring  some cost of implementing a  
feature.

And its not clear to me that you're saying that you don't see a use- 
case for image maps or input image maps. It sounds like you're saying  
that server-side input image maps are already provided, so why  
provide client-side image maps. Its not clear which thing your asking  
for use-cases for: A) client-side; or B) image maps. If its B, I've  
provided some possible use-cases (Laclan dismisses them as  
hypothetical). Some of the research has uncovered other use-cases  
(though those use-cases are all implemented ultimately through server- 
side  support).

However, your research has also shown that there isn't a single  
implementation that gets this client-side support right.? So HTML,  
either through our own recommendations or through add-ons, will  
support image maps., even on  <input type='image'>. Then it seems we  
should only need to describe use-cases for A: client-side. Then I  
would offer two use-cases. !) an author has no server-side access  
(either no server-side scripting skill or no ability to access  
scripting on the server. With image maps the difficulty is in  
defining the areas/regions  the image and that has to be done whether  
its done on the client on the server or through slicing the image  
into little bits; 2) a visually impaired user cannot see the image to  
click on it. However, this user's aural browser can present the  
alternate |area| choices to the user complete with @alt equivalents  
so that this user can select the appropriate part of the  <input  
type='image'> and submit the form accordingly.

Take care,
Rob

Received on Wednesday, 15 August 2007 21:55:31 UTC