- From: Robert Burns <rob@robburns.com>
- Date: Thu, 16 Aug 2007 00:46:33 -0500
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: public-html <public-html@w3.org>
Hi Lachlan, On Aug 16, 2007, at 12:07 AM, Lachlan Hunt wrote: > > Robert Burns wrote: >> The assumption may be wrong or it may be right. The point is, it >> just doesn't matter. Let's assume that all of these authors were >> just typing randomly and happened to type <input type='image' >> usemap='*'>. Then the number of authors trying to use this HTML >> 4.01 feature that has not been implemented is 0%. > > 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. @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|. 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. When properly implemented (which hasn't happened) @usemap on |input| has clear use-cases. I've provided examples before. And yes authors jump through all sorts o hoops to implement functaionality when its not implemented in browsers. However, this is some fairly tough stuff to do in javascript. I've already raised the image slice solution and the problems associated with that. So yes there are some very horrible solutions that authors turn to because the implementations do not meet their needs or the vision of client-side image maps in the HTML 4.01 recommendation. So why not make this easier for authors. Why not provide image maps where the UI in a web application can begin to rival the desktop (without all sorts of crazy steps). That requires an interoperable implementation . That requires cooperation with the CSS WG. It requires all sorts of things, but to simply say authors can continue pursuing these horrible hacks they already have, is ridiculous. What happened to the PAVING of the cowpaths. Now you just want to tell them the dirt path is good enough for them. > [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> This example I already provided[1] is a better example that reflects what client-side image maps are for. Again, it doesn't work right in any browser (Firefox comes the closest but it's not saying much). This example would be a horrible chore to reproduce with javascript. As I said before it involves implementing basic browser features with javascript: features that should already be implemented by the browsers. Slices can work, but that's a tedious process that causes many needless trips to the server when image-maps involve no extra trips to the server. So there are other horrible solutions to the client-side image-map. Should we make that a design principle: solutions should be horrible to author. Take care, Rob [1]: <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C% 21DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cmap%20name%3Dm%3E%3Carea%20title %3D%27left-side%27%20alt%3D%27right-side%27%20shape%3Drect%20coords% 3D0%2C0%2C100%2C100%20href%3D%3E%3C/map%3E%0A%3Cform%20action%3D.%3E% 3Cinput%20title%3D%27left-side%27alt%3D%27left-side%27%20type%3Dimage% 20src%3Dimage%20usemap%3D%23m%3E%3C/form%3E>
Received on Thursday, 16 August 2007 05:46:44 UTC