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

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<mailto: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.

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<mailto: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? 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.

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<mailto: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.