- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 23 Jun 2010 01:10:06 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: HTML WG <public-html@w3.org>
On Tue, Jun 15, 2010 at 4:05 AM, Sam Ruby <rubys@intertwingly.net> wrote: > We have a change proposal to modify 4.8.10 the canvas element section of the > HTML5 specification to allow the usemap attribute to be applied to the > canvas element: > > http://www.w3.org/html/wg/wiki/ChangeProposals/addimagemaptocanvas > > At the present time, we have no counter proposals. Accordingly, the chairs > are issuing a call for consensus at this time. If there are no objections, > we will adopt this change proposal on June 22, 2010. Sorry for the delay, I missed this call. I object to this proposal, for the reasons given in the original bug — it's a terrible idea. It doesn't come close to handling most use cases (it's on the wrong side of the 80/20 rule), it's very awkward to use (it's not an API any sane API designer would come up with if starting from first principles — it's just applying something that was designed for an entirely separate purpose to something that it was not designed for), it is incredibly difficult to use with any code that uses transforms, and it has a vastly higher implementation cost than is justified by the authoring benefit derived. All the use cases that this proposal can handle are already handled by the spec's focus ring and hit testing mechanisms, which don't suffer from any of these problems. Furthermore, because this would get used so rarely, browser vendors would likely fail to prioritise this when fixing bugs, and we'd end up with this feature being perennially buggy. It should also be noted that the change proposal does not give enough detail for the spec to be edited to address the proposal. Merely making the "usemap" attribute legal on <canvas> doesn't do anything to make usemap="" actually work on <canvas>. -- Ian Hickson
Received on Wednesday, 23 June 2010 08:10:39 UTC