Re: [whatwg] hit regions: moving an element out of the shadow tree
On Fri, 7 Feb 2014, Rik Cabanier wrote: Another question: it is currently valid to pass in a control that is not part of the canvas shadow tree. Doing this will ignore the control. Shouldn't this be invalid and throw an error? APIs don't really have a concept of valid or invalid. It doesn't throw, because the control might have just been created and the author might have painted it before adding it to the canvas. It'll work once the control is a descendant of the canvas. You can use this to temporarily stop events being propagated, while keeping the region around. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
Another question: it is currently valid to pass in a control that is not
part of the canvas shadow tree.
Doing this will ignore the control. Shouldn't this be invalid and throw an
error?
On Tue, Feb 4, 2014 at 11:05 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 4 Feb 2014, Rik Cabanier wrote:
On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson i...@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({}); :-)
Re: [whatwg] hit regions: moving an element out of the shadow tree
On Tue, 4 Feb 2014, Rik Cabanier wrote:
On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.'
[whatwg] hit regions: moving an element out of the shadow tree
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?
