Changes

Jump to: navigation, search

SVG:Pointer-events

1,261 bytes added, 14:17, 22 January 2010
no edit summary
The [http://www.w3.org/TR/SVG11/ SVG specification] introduced the '[http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty pointer-events]' property to provide SVG authors with more control over when and which parts of an element can be the target of a pointer event. This document discusses the use of the 'pointer-events' property in HTML, since HTML authors have been asking for 'pointer-events' like functionality since forever.
 
== Should clipping affect pointer event targeting? ==
 
One of the long running debates in the SVG WG and on www-svg is whether clipping and masking should affect pointer event targeting (hit testing). Current (2010) implementations do not take masking into account for hit testing, but Mozilla and Opera do take clipping into account, whereas Webkit and Batik do not. My (jwatt's) personal opinion is that it's most intuitive for authors to have both clipping and masking affect hit testing by default. In fact I think it would be best for the principle to be that the default behavior is: "if an element affects a given pixel, then a pointer event occurring at that pixel may target the element, but if the element does not affect the pixel, then the pointer event will not target the element."
 
Text should be a special case, by default. In the typical case where text is displayed at normal reading size, 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 "through" and target whatever is underneath if the click happened to be between two letters, or in the inside of an "o", say. For text, having the character cell respond to pointer events is a better default.
== The current property values suck ==
Confirm, emeritus
969
edits

Navigation menu