Re: SetElementPath Change proposal

Frank,

I started to review the latest draft of:
http://www.w3.org/wiki/Canvas_hit_testing

- It needs to state what happens when an element is deleted
- It needs to better define how hit testing will work:
"When the user interacts with the canvas, the user agent should forward the
associated events to the fallback element.
If two or more elements have overlapping paths (set via setElementPath())
the last call to setElementPath() applies."


Also, you should make use of the word dispatch vs. forward and you should
also say how you are going to use the canvas isPointInPath function:
http://dev.w3.org/html5/2dcontext/#dom-context-2d-ispointinpath


This is for hit testing so we are referring to pointer events.


- It limits the path to a focus ring. We cannot limit this t focusable
elements. This:
When setElementPath() is called, the drawing path is used to form the focus
ring provided that drawing path contains a closed path. The drawing path is
used to form a best fit bounding rectangle in screen coordinates. The
bounding rectangle and drawing path may be used to enhance accessibility
properties [ARIA] for the targeted element.

should be:

When setElementPath() is called, the drawing path is used to form the
bounds of the associated elementprovided that drawing path contains a
closed path. The drawing path is used to form a best fit bounding rectangle
in screen coordinates. The bounding rectangle and drawing path may be used
to enhance accessibility properties for the targeted element.
- in your step 2 I would use text that Ian has used for focus rings. Such
as follows:

Optionally, inform the user that the element is at the location given by
the path. User agents may wait until the next time the event loop reaches
its "update the rendering" step to optionally inform the user.


"Inform the user", as used in this section, could mean calling a system
accessibility API, which would notify assistive technologies such as
magnification tools. To assist a magnifier in zooming to an arbitrary
element, a system accessibility API must be exposed to a screen magnifier
that coveys the bounds for the object. The magnifier needs the bounds of
the object and its UI semantics in order to properly position the magnifier
around the object. The methods above are intended to enable this by
allowing the user agent to report the bounding box of the path used to form
the bounds of the element element passed as an argument.






Rich Schwerdtfeger



From:	Steve Faulkner <faulkner.steve@gmail.com>
To:	public-canvas-api@w3.org,
Cc:	ChCharles Pritchard <chuck@jumis.com>, Frank Olivier
            <franko@microsoft.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS
Date:	12/14/2011 06:17 AM
Subject:	HTML Canvas 2D Context Extensions - for review



Hi all,

HTML Canvas 2D Context Extensions
http://dev.w3.org/html5/canvas-extensions/Overview.html

"This specification extends and overrides the HTML Canvas 2D Context
specification [CANVAS-2D] with additional features for caret and
selection management, for setting the caret blink rate, for returning
the vertical offset of a text anchor point, and for drawing a focus
ring around the current path.

This document is a proposal that is being made available for public
review in order to solicit feedback, particularly from implementors,
with a goal of potential cross-browser implementation and
standardization. "

many thanks to Mike Smith for making this happen.

note: I am acting as editor until someone with the requisite knowledge
steps up.

--
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html