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 09:42:41 +0100
Message-ID: <AANLkTimUqFX4OY0zn9QhpSHJkQKDAhRsAiDSYl-cXH90@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
>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)

merely invoking the 80/20 rule without providing any data means nothing.

>and it has a vastly higher implementation cost than is justified by the
authoring benefit derived.

At least one browser vendor (Opera) has suggested that part of the appeal is
that the implementaion costs are minimal. apple have indicated that would
implement and microsoft support it, Firefox accessibility people indicated
support for the idea. So where is the pushback from?

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

how do you back up your claim it would be used "so rarely"?

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 08:43:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:18 UTC