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

That got me a little confused. In Level 2, id appears required in the webidl section, but I see lower down it says optional. I'll set it back to optional. However, if you have everything optional, it doesn't sound like you have a hit region.

How do the additional hitRegion and hitRegionList interfaces look?



From: Rik Cabanier [mailto:cabanier@gmail.com]
Sent: Friday, March 28, 2014 10:52 AM
To: Jay Munro
Cc: Jatinder Mann; Mark Sadecki; Philippe Le Hegaret; Rik Cabanier (cabanier@adobe.com); Richard Schwerdtfeger; Canvas; HTML A11Y TF Public
Subject: Re: Canvas Sub-Group Meeting Scheduled [Monday: 17 MAR 2014]



On Thu, Mar 27, 2014 at 6:45 PM, Jay Munro <jaymunro@microsoft.com<mailto:jaymunro@microsoft.com>> wrote:
For the id, it sounds like we're back and forth here. Rik spoke of an example where the hit region covers an area not associated with a single control, so it would need the id.

For Canvas level 1, to be compatible with level 2, we'll need to have control as not required (unless we change level 2).  If we keep ID, it'll have to be required to match level 2. If both id and control are optional, then when you create a hit region, it'll require one or the other. If both are null or empty string, it should abort.

That sounds good to me.

If we have just the control (no id) in level 1, then it sounds like it'll have to be required, otherwise there's nothing to hang the Hit Region on.  However, in level 2, we then make control optional, with the addition of ID (required) and Path (another possible identifier?) .

For the time being, I left ID in and set it as required in the spec. I switched pixels to path in a few places per our discussion in A11y/canvas meeting.

Not sure I follow. Why did you make ID required?

For the Hit Region List and a way to access it, here's first my stab at those.  I haven't put them into the spec yet.

Interface hitRegion {
     attribute HitRegionOptions; //  To get or set control/id, or other dictionary members
}

Interface  hitRegionList   {
    readonly attribute unsigned long length;
    getter hitRegion (HitRegionOptions index);  // to find a hit region, either hitRegion.control or hitRegion.id would be required
}


If we stick with these interfaces, or something like them, we'll have to submit a bug to the WhatWG and add them to the level 2 spec.

Comments?

--Jay



From: Rik Cabanier [mailto:cabanier@gmail.com<mailto:cabanier@gmail.com>]
Sent: Thursday, March 27, 2014 8:26 AM
To: Jatinder Mann
Cc: Jay Munro; Mark Sadecki; Philippe Le Hegaret; Rik Cabanier (cabanier@adobe.com<mailto:cabanier@adobe.com>); Richard Schwerdtfeger; Canvas; HTML A11Y TF Public

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



On Thu, Mar 27, 2014 at 8:05 AM, Jatinder Mann <jmann@microsoft.com<mailto: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<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.

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<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?

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

That will introduce even more complexity :-(
There's no chance that this could land in the near future.