Re: Canvas 1.0

+10 We are on the same page.

I asked for hit testing from day one (probably 2 years ago now) but we did
not think we could get it into Canvas 1.0 and there was some resistance to
doing hit testing from some of the HTML working group members early on -
probably for the same reason of delaying a 1.0 release.

Some history: The earliest accessibility API implementations grabbed the
location from the device context which was tied to a window handle. The hit
testing in Windows grabbed the same location (bounds) in combination with
clip regions to route mouse events for hit testing. I know this as I also
built the first offscreen model for Windows and OS/2 PM on OS/2 for Screen
Reader/2 and I was involved with the early MSAA reviews (1995).

Windows is nothing more than a big bitmap (canvas) backed by a com tree
(Canvas fallback content) and the OS manages hit testing among the
objects. ... an MVC architecture.

We should simply call it addHitRegion. We will need this for more than
accessibility as hit testing allows the developer to route the mouse events
to the same elements where they are handling the keyboard. I agree that if
it is called hit region then it should deliver what is advertised so as not
to confuse developers. The nice thing is they get some accessibility for
free. The other reason we need hit testing is for mobile devices where
assistive technologies, like screen readers, rely heavily on touch. If we
don't map the location/hit testing to the glass it won't work.

I think the hit testing is fairly straight forward to implement. ...
Basically perform an isPointInPath (perhaps a little more for z-ordering or
do it based on the last thing drawn) and when you get a hit do a dispatch
of the event to the corresponding fallback element. It is not rocket
science. This capability has been in GUI desktops since the late 1980s:
Mac, Windows286, etc.  It is proven so we should use it.

Steve Faulkner pinged me this morning that the hit test and
drawFocusIfNeeded is more or less working now on FF. Kudos to Rik Cabanier
and the Mozilla team.

I do think we need to have a remove hit region.

Rich

Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Rik Cabanier <cabanier@gmail.com>, Jatinder Mann
            <jmann@microsoft.com>, Mark Sadecki <mark@w3.org>, Canvas
            <public-canvas-api@w3.org>
Date:	02/26/2014 12:39 PM
Subject:	Re: Canvas 1.0



I can't speak for all of Chrome, but I think we'll get a lot of resistance
to shipping an API that doesn't do what it sounds like it will do.
addHitRegion sounds like it can be used for hit testing - and the whatwg
spec says that's what it should do. I don't think we should add an
interface called addHitRegion that doesn't actually do hit testing.

We renamed drawSystemFocusRing to drawFocusIfNeeded so that the name
matches exactly what it does. Why not do the same thing here?

How about addAccessibleRegion, or just addRegion?

Alternatively, if Mozilla wants to implement hit testing I think there's a
much better chance we could ship that. It would take longer to develop - it
looks a bit tricky - but I think it would be easier to argue for it.

- Dominic

On Tue, Feb 25, 2014 at 6:07 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  Hi Dominic,

  We are trying to flush out an agreement for 1.0.

  Mozilla has implemented using the HitRegion API to bind the location with
  the fallback element. We are trying to deliver the minimal implementation
  for 1.0 that would allow us to support accessibility. We can't get Path
  done in a reasonable amount of time so we would use the current path. I
  am a bit uncomfortable about not adding actual hit testing. If we were to
  include that in the proposal would that satisfy a meets minimum for you
  for 1.0?

  My concern about not having hit testing is mobile touch devices and
  working with AT like VoiceOver and TalkBack with touch. The question is
  should we do this in 1.0 or 2.0. Regardless we will continue to work on
  other features of hit testing API in 2.0 - such as adding Path object
  support.

  I suspect we will also require a removehitregion in response to Charles
  later response.

  Rich


  Rich Schwerdtfeger

  Inactive hide details for Dominic Mazzoni ---02/24/2014 05:46:19
  PM---Wait, to clarify, addHitRegion would not actually provideDominic
  Mazzoni ---02/24/2014 05:46:19 PM---Wait, to clarify, addHitRegion would
  not actually provide hit testing? Is the idea that it'd be adde

  From: Dominic Mazzoni <dmazzoni@google.com>
  To: Richard Schwerdtfeger/Austin/IBM@IBMUS
  Cc: Mark Sadecki <mark@w3.org>, Rik Cabanier <cabanier@gmail.com>,
  Jatinder Mann <jmann@microsoft.com>, Canvas <public-canvas-api@w3.org>
  Date: 02/24/2014 05:46 PM
  Subject: Re: Canvas 1.0




  Wait, to clarify, addHitRegion would not actually provide hit testing?

  Is the idea that it'd be added in the next spec revision? It seems odd to
  do this, the feature would ship in a way that doesn't really match the
  original intent of the spec.

  I thought Mozilla already implemented some of the actual hit testing
  features.

  - Dominic

  On Mon, Feb 24, 2014 at 3:28 PM, Richard Schwerdtfeger <schwer@us.ibm.com
  > wrote:
        Hi Dominic,

        For version of the canvas 1.0 spec. we would like to have the
        following in the specification.

        1. addHitRegion but only with an optional id and a fallback element
        to associate the element (this will set the location).   e.g.
        addHitRegion(id,control) where control would be any fallback
        element at this time.
        2. drawFocusIfNeeded but remove the step that sets the location.

        1. This would not provide actual hit testing but it would assign
        the location at this time

        We would need you to agree and implement this in Chrome now and we
        would work to address the other additions to the addHitRegion spec.
        (from WhatWG) in v2.0. We also want your feedback on the spec.
        changes.

        Rich

        Rich Schwerdtfeger