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

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.