Confirm, emeritus
969
edits
Changes
→Should clipping affect pointer event targeting?
# Provide a way to allow pointer events to be "caught" by an element even when it is invisible to the user.
== Should The effect of clipping affect pointer event targeting? and masking ==
One of the long running debates in the SVG WG and on www-svg is whether an element should intercept pointer events if the event is over an area of the element that is clipping away or masked out. Current (2010) implementations do not take masking into account for hit testing, but Mozilla and Opera do take clipping into account, while Webkit and Batik do not.
Text needs to be a special case, by default. When a user wishes to click on it to activate a link, or perhaps to select it, it would be unexpected and annoying for the pointer event to go between letters or through the middle of an "o", say, and target whatever is underneath. For the purposes of hit testing text the character cell is used as the fill area for a glyph by default. However, for large text, having event interception depend on the inked area instead of the character cell could be what authors want. We should really provide them with some way to do that. (Another property they can set?)
== The effect of filters ==
Filters can significantly expand/contract or move elements.
A case where authors would not want filters being taken into account: Consider an SVG object where a filter is used to give it a shadow. Perhaps the object is an image of a man in a game where the shadow is being cast along the floor. Authors would not want pointer events that hit the man to act as if the man was hit.
A case where authors would want filters to be taken into account: Consider again the case of an image of a man in a game, but this time a filter is used to make him appear wasted and thin.
feOffset could potentially make hit testing appear all off.
== The effect of markers ==
Rather than modifying the DOM to add and manage drag handles to an editable object, life could be a lot simpler if markers could be used to create drag handles. (Would that really work well? How would you distinguish between different types of handle, and whether the user is trying to drag or resize, for example.)
== The current property values suck ==
