W3C home > Mailing lists > Public > public-html@w3.org > June 2012

ISSUE-201: Aligning the two change proposals

From: Frank Olivier <Frank.Olivier@microsoft.com>
Date: Wed, 6 Jun 2012 18:27:48 +0000
To: "public-html@w3.org" <public-html@w3.org>
CC: "Edward O'Connor (eoconnor@apple.com)" <eoconnor@apple.com>
Message-ID: <91175A762AB48840AF1473514B26B47552A5647E@TK5EX14MBXC262.redmond.corp.microsoft.com>
I've reviewed the two change proposals for ISSUE-201; this is my proposal for aligning the two:
We have the following similarities/differences between the two:

Both change proposals have a method for adding a hit region to a canvas and associating it with a DOM element. 

I'm happy to have this called addHitRegion() [Eoconnor's CP]; I think we should modify the definition slightly, however:
Remove the path argument (The default path seems sufficient for solving the accessibility issue; Path primitives can be added to a future version of the specification.) id should not be optional - as we need a unique id for a removeHitRegion() method.

Differences that I would keep:
[Frank's CP only] A method ( clearElementPath() ) to remove hit regions. I think we should have this in the joint proposal, as relying on ClearRect or other drawing mechanisms to clear an association seems overly involved and a burden on the author.

Adding a simple method called removeHitRegion(DOMStringid) would be sufficient here.

[Eoconnor's CP only] The ability to associate a hit region with a lightweight (non-DOM element) accessibility object. As we discussed in the May meeting, I think this is a good addition with useful use cases.

The following are useful edits to improve the quality of the spec:
r7037 - Make addHitRegion() consistent with context.fill() in using the context's transformation matrix, not a separate transformation.
r7039 - Correct the focus ring API definitions to notify the user appropriately.

The following is not in scope for solving accessibility and are more appropriate for a future version of the spec:
r7023 - Path objects and drawing text to a path or along a path. Note that there's not yet any way to _use_ the Path objects. That's next... - yes
r7024 - Make it possible to draw Path primitives to the canvas. yes
r7025 - Add ellipse support to canvas. not needed, not accessibility
r7026 - Add SVG paths to Path objects in canvas.
r7028 - add dashed lines and change how Path objects work to instead use external line and font styles and transformation objects
r7029 - Make it easier to do hit testing on canvas needed
r7033 - More font metrics.
r7034 - Path copy constructor
r7038 - Make the width values usable in practice.

I'd like to get more feedback from Ted O'Connor and others on this proposal to solve the accessibility issue in 201.

Received on Wednesday, 6 June 2012 18:28:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:53 UTC