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

On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com> wrote:

>
> Hi all,
>
> I got this note from Jacob Rossi, one of our PMs who reviewed the spec.
> Some food for thought.
>
> *         Accessing regions by a string ID seems like a clumsy API and
> requires me to keep my own model that tracks the regions and their IDs.
>

That is correct. I'm unsure if that is a problem. Wouldn't an author know
the id's he used to create a region?



>         o   Also the ID is optional, meaning some hit regions could be
> lost forever?
>

No, the ID is only optional if you provide a control.
If you remove the control, the hit region it is backing will be destroyed
as well.


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


>                  If IDs were scrapped, then the MouseEvent.region
> extension isn't needed. This would be my preference.
>
> *         ID string is listed as optional, control is not. But yet from
> the algorithm for addHitRegion(), it seems control is also optional?
>

Yes, that is odd. You should be able to specify both or one.
Having none should be an error.


> *         The argument type for add/removeHitRegion(), HitRegionOptions,
> is not defined anywhere in the spec. I think this should be a dictionary
> type most likely.
>

Yes, the HitRegionOptions dictionary is missing from the ID section.


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


> 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.
Last week, Rich mentioned that he expects the regions to act like their
underlying controls but I don't see that in the spec.
The spec also talks about "retargeting" the event, but doesn't say what
that means. In the WhatWG version, I *think* it states that default
behavior should happen (ie a button that gets a click event should act as
if it's clicked, a link should be followed, etc) but the w3c version is
silent about this.

I would prefer if we could simplify even handling so all it does it update
the id in the mouse or touch event...
The 'contol' in that case, would only be used for accessibility.