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

On Thu, Mar 27, 2014 at 6:45 PM, Jay Munro <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]
> *Sent:* Thursday, March 27, 2014 8:26 AM
> *To:* Jatinder Mann
> *Cc:* Jay Munro; 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 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.
>
>
>
>
>