Re: ISSUE-201: canvas-fallback - Chairs Solicit Alternate Proposals or Counter-Proposals

On 4/12/2012 8:03 AM, Edward O'Connor wrote:
> Hi Steve,
>
> You wrote:
>
>>> I would be appreciative if you could provide in your change proposal,
>>> rationale and any details of how this aspect of hixie's hitregion()
>>> may be implemented to hook up with accessibility APIs:
>>> An unbacked region description consists of the following:
>>> Optionally, a label.
>>> An ARIA role, which, if the unbacked region description<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-region%27s-unbacked-region-description>  also
>>> has a label, could be the empty string.
>> no rationale is provided for this aspect.
> Rationale is provided for unbacked region descriptions; see the
> paragraph beginning "DOM elements are expensive…".
>
> Oh, now I see that you also asked for "details of how [unbacked region
> descriptions] may be implemented to hook up with accessibility APIs."
> Describing such details is out of scope for the HTML spec, so I don't
> see why people would have to provide such detail in a Change Proposal.
> I note that the only other Change Proposal on the table for ISSUE-201
> also doesn't provide such detail.
>

I've written up counter-arguments addressing some of the assertions made 
in your proposal:
http://www.w3.org/html/wg/wiki/User:Cpritcha/ISSUE-201-eoconnor-counter

TL;DR: DOM elements are not expensive. This is provable. Further, 
lightweight elements are not sufficient for accessibility. They lack 
sufficient semantics. There's no means of providing them.

It seems to me, as we are dealing with computers, that there ought to be 
a means to prove these cases empirically. I spent a good deal of time 
working with the Canvas tag before approaching the WHATWG. I spent a 
good deal of time working with solutions while working with the Canvas 
WG. I am confident that the proposal being put forward by Atkins-Hixie 
is an immature proposal reflecting many of the early mistakes I made in 
my own experiments in the area. Unfortunately, there seems to be a 
credibility gap.

Aside from that dark cloud, there is a silver lining here. Many vendors 
had confused the Canvas WG recommendation for addEventTarget (or 
"addHitTesting") as an attempt to graft a "Retained mode" API onto 
Canvas. It seems now that we have full consensus across vendors and spec 
editors that an addEventTarget method should exist the Canvas 2d API and 
that it should work with the current path and bind to an element in the 
DOM node.

That's great. I'm really glad we were able to develop that consensus. 
The "retained mode" thread was quite lengthy and the months leading up 
to it were loud with discordance.

I object to the new "Path" object proposal. It's half baked; neither the 
SVG2 WG nor WebGL users were consulted on the issue. It's completely 
unnecessary for ISSUE 201.

I've authored a simple patch for WebKit which adds the very simple 
createPath opaque CanvasPath object as well as the TextMetrics baseline 
property. These enhancements are sufficient and much simpler.
If at some point, a Path object is created that fulfills the needs of 
WebGL and SVG2, I would gladly support it in addition to the opaque 
CanvasPath object.

-Charles

Received on Friday, 13 April 2012 07:27:57 UTC