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