- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 27 Mar 2014 08:25:46 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: Jay Munro <jaymunro@microsoft.com>, Mark Sadecki <mark@w3.org>, Philippe Le Hegaret <plh@w3.org>, "Rik Cabanier (cabanier@adobe.com)" <cabanier@adobe.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Canvas <public-canvas-api@w3.org>, HTML A11Y TF Public <public-html-a11y@w3.org>
- Message-ID: <CAGN7qDA7PddfstYsxuRAp9HXvT41EvTOTVSkycWHxmjLNM63Hg@mail.gmail.com>
On Thu, Mar 27, 2014 at 8:05 AM, Jatinder Mann <jmann@microsoft.com> wrote: > On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote: > > >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com> > wrote: > > >> I'd 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. > > > > > > No, it makes sense to create regions without a control. > > > For instance, if you draw a dialog with a button on top of other > controls, you will need to create a region > > the size of the dialog to obscure the controls at a lower z-order > > > > In Monday's meeting, Rich mentioned that the unbacked region is a Level 2 > concept. Is that true? If so, in Level 1 control shouldn't be optional. And > if control isn't optional, why have a separate ID? You can always just use > the id attribute of the element. > That is correct. However, in order to make existing code work once we update the implementations to level 2, I don't think we can change this. http://w3cmemes.tumblr.com/post/74777199794/professor-tab-says-be-nice-to-the-time-space > Even if control is optional, I wonder if it's worth adding an ID when you > can always just use the id attribute of the element. The additional benefit > here being you can scrap the MouseEvent.region extension as well. > > > > On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote: > > >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com> > wrote: > > >> * There doesn't seem to be a way to access the collection of > added hit regions. I'd expect something > >> like context.regions to expose a collection of the added regions. > > > > > > Yes. > > > > Any thoughts on how you'd like to expose this? > No, I haven't given it much thought > We can have a method return a list of regions or an attribute that > contains the set of regions. Also, do we want to provide a method to update > those regions or do we expect developers to remove and then add a new > region. > The expectation is that developers just add a region with the same id and/or control which will remove the existing one. > On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote: > > >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com> > wrote: > > >> o E.g. it currently seems I have to remove and add a hit region if I > just want to update it. > >> Perhaps it's felt this isn't needed in an immediate-mode graphics API? > >> * Spec should also handle PointerEvents too! > > > > > > I think event handling is underspecified. > > I think we should support PointerEvents as well. The event handling > section does need more work. > That will introduce even more complexity :-( There's no chance that this could land in the near future.
Received on Thursday, 27 March 2014 15:26:17 UTC