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

Re: ISSUE-201: Aligning the two change proposals

From: Edward O'Connor <eoconnor@apple.com>
Date: Fri, 22 Jun 2012 17:47:57 -0700
Message-id: <16733EC1-7E0D-47D5-B5C6-A0F92B3E4DDB@apple.com>
To: HTML WG <public-html@w3.org>
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 00:48:33 UTC

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