W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2014

RE: Canvas Sub-Group Meeting Scheduled [Monday: 17 MAR 2014]

From: Jay Munro <jaymunro@microsoft.com>
Date: Tue, 18 Mar 2014 04:10:26 +0000
To: Mark Sadecki <mark@w3.org>, Philippe Le Hegaret <plh@w3.org>, "Rik Cabanier (cabanier@adobe.com)" <cabanier@adobe.com>, Jatinder Mann <jmann@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>
CC: Canvas <public-canvas-api@w3.org>, HTML A11Y TF Public <public-html-a11y@w3.org>
Message-ID: <b3550b0cb2b94280b34cb3734cc47b20@BY2PR03MB521.namprd03.prod.outlook.com>

Hi all,

I got this note from Jacob Rossi, one of our PMs who reviewed the spec. Some food for thought.

         Accessing regions by a string ID seems like a clumsy API and requires me to keep my own model that tracks the regions and their IDs.
        o   Also the ID is optional, meaning some hit regions could be lost forever?
        o   Id actually recommend just scrapping the ID concept altogether and focus on the control nodes. In fact, add/RemoveHitRegion() could just take a control as the only arg. If you want an ID, just use the ID attribute on the control node.
                 If IDs were scrapped, then the MouseEvent.region extension isnt needed. This would be my preference.

         ID string is listed as optional, control is not. But yet from the algorithm for addHitRegion(), it seems control is also optional?
         The argument type for add/removeHitRegion(), HitRegionOptions, is not defined anywhere in the spec. I think this should be a dictionary type most likely.
         There doesnt seem to be a way to access the collection of added hit regions. Id expect something like context.regions to expose a collection of the added regions.
o   E.g. it currently seems I have to remove and add a hit region if I just want to update it. Perhaps its felt this isnt needed in an immediate-mode graphics API?
         Spec should also handle PointerEvents too!
Received on Tuesday, 18 March 2014 04:11:02 UTC

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