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

FW: ISSUE-201: Aligning the two change proposals

From: Paul Cotton <Paul.Cotton@microsoft.com>
Date: Sat, 23 Jun 2012 16:07:46 +0000
To: "Richard Schwerdtfeger (schwer@us.ibm.com)" <schwer@us.ibm.com>, Frank Olivier <Frank.Olivier@microsoft.com>
CC: "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "Edward O'Connor (ted@oconnor.cx)" <ted@oconnor.cx>
Message-ID: <AB5704B0EEC35B4691114DC04366B37F11944C@TK5EX14MBXC125.redmond.corp.microsoft.com>
Resending to include Rich and Frank in the To: field and the A11Y TF in the CC: field.  I recommend that discussion take place on the public-html@w3.org email at:


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

-----Original Message-----
From: Edward O'Connor [mailto:eoconnor@apple.com] 
Sent: Friday, June 22, 2012 8:48 PM
Subject: Re: ISSUE-201: Aligning the two change proposals

Hi all,

Frank and I got together today and went through the remaining ISSUE-201 items.

Frank wrote:

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

Frank and I talked about why one might want Path primitives--using the current path for hit regions is fine so long as the thing you're currently drawing corresponds to a hit region; it's really awkward to have to manipulate the current path (whose sole purpose is drawing) to define a hit region that doesn't have a corresponding drawing operation. Frank thought having an exposed Path object for this case would be fine.

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

We both agreed that having a clearElementPath() method makes sense.

> 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

See paragraph above; I think we can keep an exposed path object for the a11y case.

Given an exposed Path object in canvas pre-HTML.next, I think several of the following changes make sense to happen now, but some could be put off until HTML.next.

> r7025 - Add ellipse support to canvas. not needed, not accessibility

Agreed; can wait.

> r7026 - Add SVG paths to Path objects in canvas.

Agreed, can wait.

> r7028 - add dashed lines and change how Path objects work to instead use external line and font styles and transformation objects

I need to look at this in more detail to see if the refactoring is necessary to make Path sufficiently useful.

> r7029 - Make it easier to do hit testing on canvas needed

Sounds like we need this.

> r7033 - More font metrics.

Definitely helps wit hit testing runs of text, so I'd prefer to keep this in. That said, I can live with putting it off until HTML.next.

> r7034 - Path copy constructor

I don't see the harm in keeping it, but like the font metrics, I can live with putting it off as well.

> r7038 - Make the width values usable in practice.

In general, I prefer usable features to unusable features. :)

Received on Saturday, 23 June 2012 16:08:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC