ISSUE-201: Aligning the two change proposals

Does this mean that the ligtweight JSON objects will be an html.next
discussion item?

Rich


Rich Schwerdtfeger

----- Message from Paul Cotton <Paul.Cotton@microsoft.com> on 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>           
                                                                                                                              
  Subject: 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