Re: hixie has proposals for regions and path primitives additions to the 2d context spec

Hi Charles,

I did provide feedback to Hixie offline although I have not had a chance to
review his latest draft. I will review when I have cycles this week. I am
hosting an ARIA face to face meeting in Austin.

Rich


Rich Schwerdtfeger



From:	Charles Pritchard <chuck@jumis.com>
To:	Steve Faulkner <faulkner.steve@gmail.com>,
Cc:	public-canvas-api@w3.org, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Date:	03/03/2012 01:18 PM
Subject:	Re: hixie has proposals for regions and path primitives
            additions to the  2d context spec



The main take-away here is that the HTML5 editor has put forward a rough
proposal of region-based hit bound to DOM elements. That's great. That's
some progress three years in the making.

We've yet to hear back from Apple and Mozilla about this methodology. Apple
responded last year that they did not believe Canvas should be used with
"retained mode" semantics. They've not been back. When/if Apple and Mozilla
are on-board, we can claim a broad consensus that region-based hit testing
should be added to the API.

As for Hixie's current proposal: addHitTesting; I'd prefer it was called
"addEventTarget".

Hixie proposes two new features: virtual elements, and binding strokeText
and fillText by default to the a11y API.

I am tempted by the virtual element proposal. As of yet, the SVG WG has not
taken up David Dailey's replicate semantics. Those semantics cover the main
cases I've relied on Canvas for: free-form drawing and stylized glyphs.
They've been rejected from SVG2, so far. I'm still arguing that they're
necessary for a decent implementation of InkML rendering in SVG.

SVG Replicate:
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

Hixie's virtual elements are light elements that are not present in the
DOM, but do contain: "role", "label" and an identifier. I'm tempted by
them, but I'm concerned that departing from the DOM will mean shrugging our
responsibility to keep things programatically accessible.

Building on the virtual elements feature, Hixie suggests that all existing
instances of strokeText and fillText should create an accessible object,
its label being the content of the text passed through the methods.

I am again concerned: while this would certainly have benefits with some
existing Canvas pages, it may result in a whole lot of duplicates in the
accessibility tree, and may not work with many situations currently used
today with animation and glyph painting.

It may require additional clearRect calls instead of simple fillRect calls,
and could otherwise add complexity and confusion to the API. It simply
doesn't fit with current semantics.

I have to come out against virtual elements at this time.

I am glad to see that binding the current path to a sub-tree element (in
the DOM) was included in Hixie's proposal. Frank Olivier, Hixie, myself and
Richard have suggested this feature.

At present, Hixie's proposal is a bit far reaching, and re-engages some of
the earlier ideas that floated around last year, such as using clearRect to
clear the canvas. For reasons we've previously discussed, I don't think
these kinds of features are appropriate for the Canvas API.

-Charles

On 2/27/2012 10:01 PM, Steve Faulkner wrote:
      hi all,

      hixie has proposals for regions and path primitives additions to the
      2d context spec

      http://wiki.whatwg.org/wiki/Canvas#Proposals


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