- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 30 Mar 2011 15:51:01 -0500
- To: Oliver Hunt <oliver@apple.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com, cyns@exchange.microsoft.com, david.bolter@gmail.com, faulkner.steve@gmail.com, franko@microsoft.com, public-canvas-api@w3.org, public-canvas-api-request@w3.org, public-html@w3.org, public-html-a11y@w3.org, public-html-request@w3.org
- Message-ID: <OF67B87C43.8E224ED0-ON86257863.0071CC92-86257863.007288AE@us.ibm.com>
Oliver,
GDI provides and infrastructure that supports hit testing in Windows. The
bounding rectangle of each device context is bound to the object and used
in hit testing along with Z-order, etc. What I am telling you is that many
developers are using canvas beyond the limitations and not going to SVG
because for people working in the Windows space Canvas is closer to what
they know. I am also saying that we need a vehicle for supplying the bounds
of a UI object for accessibility. This has, on Windows, been tied to this
device context bounding rectangle.
>From an accessibility perspective telling a developer they should not do
something in canvas easily so go use SVG does not work.
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
From: Oliver Hunt <oliver@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com,
cyns@exchange.microsoft.com, david.bolter@gmail.com,
faulkner.steve@gmail.com, franko@microsoft.com,
public-canvas-api@w3.org, public-canvas-api-request@w3.org,
public-html@w3.org, public-html-a11y@w3.org,
public-html-request@w3.org
Date: 03/30/2011 02:20 PM
Subject: Re: feedback requested: Canvas change for improved hit testing
that also facilitates accessibility
On Mar 30, 2011, at 12:06 PM, Richard Schwerdtfeger wrote:
Oliver,
It is an attempt to simplify hit testing in canvas while at the same
time providing a vehicle to tell an assistive technology the bounds
of the corresponding UI object being drawn on canvas as represented
in fallback content. Currently there is no mapping. These bounds are
needed by screen magnifiers for zooming and screen readers for
Braille support (earlier post).
Now the canvas author has to manage all the hit testing. This is a
canvas deficiency that should have been in place to start - so
grafting seems like an inappropriate response. Consequently, I am
also seeing canvas applications that create the equivalent of visio
by creating separate canvas elements overlayed on top of another
canvas to represent drawing objects. This is very inefficient and
will get worse unless something is done.
This is not a canvas deficiency -- canvas is an immediate mode renderer,
one of the things you have to handle yourself when dealing with _any_
immediate mode renderer is hit detection. This is true of Canvas, GDI, CG,
raw component painting in Java, etc, etc
If you want hit detection to be done for you, you want a retained mode
renderer, such as SVG.
--Oliver
Rich Schwerdtfeger
CTO Accessibility Software Group
<graycol.gif>Oliver Hunt ---03/30/2011 12:11:53 PM---This feels like
an attempt to graft retained mode rendering on to canvas, what am i
missing? --Olive
From: Oliver Hunt <oliver@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Boris Zbarsky <bzbarsky@mit.edu>, chuck@jumis.com,
cyns@exchange.microsoft.com, david.bolter@gmail.com,
faulkner.steve@gmail.com, franko@microsoft.com,
public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
, public-html-request@w3.org
Date: 03/30/2011 12:11 PM
Subject: Re: feedback requested: Canvas change for improved hit
testing that also facilitates accessibility
Sent by: public-canvas-api-request@w3.org
This feels like an attempt to graft retained mode rendering on to
canvas, what am i missing?
--Oliver
On Mar 30, 2011, at 8:39 AM, Richard Schwerdtfeger wrote:
Thanks Boris. Sorry for being a pest but I really want
developers to work through the issues.
So, you would do the following:
- Assign the a closed draw path to an element in fallback
content: setClickableRegion(element). This immediately makes
the association and places it at the bottom of the list.
- Any time you draw the element it moves it to the top of the
list.
- If the fallback element is removed the association would need
to go away. I did not address that so I will need to add that
to the proposal
- When a pointer event (click, etc.) goes to the fallback
element the normal capture/bubbling event processing would
apply
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
<graycol.gif>Boris Zbarsky ---03/30/2011 10:05:48 AM---On
3/30/11 10:55 AM, Richard Schwerdtfeger wrote: > Seeing as
nobody has commented can we assume tha
From: Boris Zbarsky <bzbarsky@mit.edu>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-canvas-api@w3.org, public-html@w3.org,
public-html-a11y@w3.org, public-html-request@w3.org,
chuck@jumis.com, cyns@exchange.microsoft.com,
david.bolter@gmail.com, faulkner.steve@gmail.com,
franko@microsoft.com
Date: 03/30/2011 10:05 AM
Subject: Re: feedback requested: Canvas change for improved hit
testing that also facilitates accessibility
On 3/30/11 10:55 AM, Richard Schwerdtfeger wrote:
> Seeing as nobody has commented can we assume that developers
have no
> problem with our totally changing the canvas 2D API to
support clickable
> regions?
It might just mean that people don't read their mailing list
spam every
few hours.
>From reading over your proposal, I'm not sure I follow how it
would
behave in the face of DOM mutations (e.g. elements being
removed from
the fallback content).
Or put another way, once you draw, you're permanently attaching
some
element to the canvas, right? Or is that not the proposal?
-Boris
Attachments
- image/gif attachment: graycol.gif
Received on Wednesday, 30 March 2011 20:51:41 UTC