See also: IRC log
<trackbot> Date: 14 April 2014
Added method clearHitRegions() http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions
RC: WHAT WG already said they
will not be making the change from pixels to paths.
... WHAT WG has a process for using a scratch bitmap to manage
regions. We are using paths for that
... clearRect has the same effect as clearHitRegions()
<plh> "Clear regions that cover the pixels in pixels in the canvas element."
JM: clearRect is still in ours as well
MS: clearHitRegions is a more elegant way of clearing hit regions.
PLH: comparing clearRect and clearHitRegions. Why the difference re garbage collection
<plh> "Garbage-collect the regions of the canvas element."
<plh> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions
<plh> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearrect
PLH: think we should take out the ref to garbage collection in clearHitREgions
AGREED
RC: I don't think we need to add WHAT WG step 4 (control represented by a region). covered by our step 3.
AGREED
RC: We have a list of paths, so we don't need such an algorithm
AGREED
RC: we use paths, so this rule doesn't apply to our spec
MS: Clipping regions
RC: That must have been added in
the last couple weeks
... it makes sense. Not sure how we would implement this.
... a hit region can be clipped
... i think we should add this to our spec but reword it so
that it deals with path and not pixels
... "remove from specified path..."
PLH: how will you clip pixels if you are working with path
RC: Clipping area is already
based on path
... test the hit region and all their clipping paths
... unless we change addHitRegion to combine the clipping
region with the current path
JM: the path resolves to pixels
in our spec, so the wording can be similar
... just not refer to fillRule
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#the-region-for-a-pixel
<plh> to be added "Remove from specified pixels any pixels not contained within the clipping region."
JM: I think path would work there.
RC: I don't think this needs to change
JM: should we remove the underscore
RC: I actually think we should change this to path. Link it to path
PLH: not sure if its easy to change the target of an event before its dispatched
RC: This would be really tricky
to implement
... in FF it would be a tremendous amount of work
PLH: Why exactly would that be?
RC: browsers default behavior,
its done in C++
... have to teach source algorithms about canvas
... probably won't have an implementation in 6 months
... makes sense to do it this way, but it would take a while to
get it implemented
PLH: WHAT WG attempts to do this
without modifying DOM event spec
... no magic here
... other way would be to dispatch event, then when you hit
canvas, dispatch a new event.
... or, once you reach canvas, change the target. that is like
magic, not specified anywhere
JM: Jatinder said we would need to talk to ?? Jacob
PLH: if we move the mouse over a region, which has a control, now I don't target that to canvas, it targets the control
RC: it bubbles up until it gets
captured
... as you are moving over it, the event target changes.
... event retargeting is not as simple as it seems
... previously we considered not sending it to fallback
contact, just send it to canvas and let the developer
manage
... that might still be forward compatible.
PLH: i think we would have to add
a method
... to help the developer
RC: it would be the region
ID
... would be filled in automatically
JM: They would get the mouse event from canvas and if the ID matches a control, there is a region
RC: Rich said he wanted to see mouse enter and leave
PLH: what was wrong with not retargeting the event?
RC: That would work for me
PLH: i say we do it this way and
get feedback from implementers. sounds like this would be
easier and the burden on authors is not that much
... doesn't change the target during mouse move. that is a win
for me
... do we want session id or control
RC: I think just the ID is enough
PLH: is there a case where dev would be interested in region ID and not the control
JM: in L1, it sounds like that would work. In L2, that might now work
PLH: might be worth it to add a
note saying that we won't be adding support event
re-routing
... just support for region id