[whatwg] hit regions: moving an element out of the shadow tree

[Ian Hickson]

On Tue, 4 Feb 2014, Rik Cabanier wrote:
> On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 3 Feb 2014, Rik Cabanier wrote:
> > >
> > > The spec is currently silent what should happen when an element that 
> > > is associated with a hit region, is moved to another location in the 
> > > document, another document or deleted.
> > >
> > > This should result in removal of the hit region. Maybe this is 
> > > defined in the HTML spec?
> >
> > It results in the region no longer having a backing control (see the 
> > definition of "the control represented by a region"), but why would it 
> > remove the region? The region might be there for other reasons, e.g. 
> > it might have a cursor or ID specified, or the author might be using 
> > it to play a sound when the user tries to click on the space where the 
> > control used to be drawn, to indicate to the user that the control is 
> > gone.
> 
> Ok, link: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region
> 
> It's a bit weird that you can do "ctx.addHitRegion({});" :-)

Or even just c.addHitRegion(). An author might want to do that to 
introduce a "dead" zone in a canvas, where the cursor reverts to the 
canvas default cursor, there's no AT implications, and the hit testing in 
mouse events doesn't give a region ID any more. This is similar to <area> 
elements with no href="".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'