FW: ISSUE-201: Aligning the two change proposals

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:
http://lists.w3.org/Archives/Public/public-html/2012Jun/0111.html 

/paulc

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
To: HTML WG
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. :)



Ted

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