W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: CfC: Adopt ISSUE-105 canvas-usemap Change Proposal to add usemap attribute to the canvas element

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Wed, 23 Jun 2010 10:07:32 +0100
Message-ID: <AANLkTimLQO27hgzWd5Pu-oGvyouEr-F1tE3gMMV0xtYQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
Use case example:

http://caimansys.com/painter/index.html
on the right had side are 3 widgets built using canvas
color widget
brush size widget
playback toolbar

It would be trivial for all 3 to be made keyboard accessible using an image
map and have ARIA attached to the area elements to expose the semantics
(roles, states and properties) of the interface elements.

regards
Stevef

On 23 June 2010 09:10, Ian Hickson <ian@hixie.ch> wrote:

>  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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Wednesday, 23 June 2010 09:08:28 GMT

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