Rendering and Pointer-Events (ACTION-2372, ACTION-2358)

Hi, Folks-

In preparing the SVG 1.1 2nd edition spec, we had an outstanding issue 
regarding clip-paths and pointer events.  There has been some 
disagreement on what the specified behavior should be, and 
implementations differ as to whether clipped areas of an element are 
viable targets for hit detection.  Firefox and Opera perform hit 
detection only on the rendered areas, for example, while Batik and 
WebKit only respect the inherent geometry of the shape for purpose of 
hit detection; both are reasonable interpretations in an area the spec 
has been unclear about.

Because I saw use cases for both scenarios (either clipped areas being 
sensitive to pointer events, or being insensitive), my original proposal 
for resolving the situation dealt with changing the behavior of events 
and clipped areas depending on the value of the 'pointer-events' property.

Thomas DeWeese made a very compelling counter-argument [1] that this was 
a hack, and that it would be better to simply define a new property that 
would control pointer event sensitivity, which would indeed be a cleaner 
model.

Jonathan Watt also disagreed with my proposal, on different grounds: 
that the values for the 'pointer-events' property were poorly designed 
in their names and categorizations; this is hard to argue against, and 
this is something we plan to address in SVG 2.0.

After quite a bit of discussion within the group, considering the 
various implementations and behavior of underlying rendering libraries, 
and with the goal of specifying the most intuitive behavior for authors, 
Jonathan and I (along with Patrick Dengler) worked out what we hope is a 
reasonably consistent and predictable guiding principle for deciding on 
the details for this and related issues, such as whether glyph apertures 
or the gaps in dashed strokes receive pointer events, and whether 
clipping affects the geometry and results of bounding-box calculations 
for an element.  Our guiding principles treat shapes and text 
differently by default, because of traditional expected behavior:

* By default, non-rendered areas of an element (such as those created by 
clip-paths or areas outside viewport-creating elements like symbols or 
nested <svg>s) *are not* sensitive to pointer-events

* By default, for text, all areas of a character within the "character 
cell" (the conceptual box determined by the widest, tallest, and lowest 
glyphs in the font used) *are* sensitive to pointer-events, even if not 
"rendered" (i.e. glyph apertures, counters, and non-painted areas are 
still sensitive); this extends to areas between glyphs in the same 
"block" (siblings of the same textual element which are not explicitly 
positioned via @x, @y, or @transform, for example), even when those 
areas are expanded such as with 'letter-spacing'.  Essentially, each 
character will be treated as if it has an invisible rectangle around it 
which connects to that of the other characters in the same block.

* By default, the geometry of clipped elements will not be changed by 
clipping; a rectangle with a width and height of 20 each, when clipped 
by a smaller rectangle, will still have a bounding box with a width and 
height of 20 each.

* Each of these default characteristics will, in SVG 2.0, have an 
associated modifier property which allows the author to indicate which 
refined behavior is desired.  Through these new properties, for example, 
the clipped areas may be made to react to pointer-events, glyph 
apertures and other "empty space" in a character can be made to pass 
events through, and the gaps in dashed strokes can be made to capture 
pointer-events.  We plan to add new bounding-box methods (or optional 
parameters to getBBox) to allow for various permutations of geometry, 
such as whether clipped areas are counted as contributing to the 
bounding box, and the same for filter-effects, or strokes, etc.


(So, what about a letter "O" with a very large font-size, or which is at 
a very fine zoom level?  Isn't the intuitive behavior to be able to 
click through the center of the "O" onto a shape behind it?  Yes, it 
is... but we plan to put that control into the hands of authors; by 
providing a special pointer-event property or modifier, and perhaps some 
SVG extensions to CSS media queries, this can even be zoom-, scale-, or 
font-size dependent.)


So, in resolution to the issue of pointer-events and clipping, in order 
to make sure that we have interoperable behavior between implementations 
going forward, we have settled on the following wording:

[[
14.3.6 Clipping paths, geometry, and pointer events

A clipping path is conceptually equivalent to a custom viewport for the 
referencing element. Thus, it affects the rendering of an element, but 
not the element's inherent geometry. The bounding box of a clipped 
element (that is, an element which references a ‘clipPath’ element via a 
‘clip-path’ property, or a child of the referencing element) must remain 
the same as if it were not clipped.

By default, pointer-events must not be dispatched on the clipped 
(non-visible) regions of a shape. For example, a circle with a radius of 
10 which is clipped to a circle with a radius of 5 will not receive 
'click' events outside the smaller radius. Later versions of SVG may 
define new properties to enable fine-grained control over the 
interactions between hit testing and clipping.
]]

We hope this satisfies people who had concerns and questions on the 
matter.  We recognize that some may disagree with this conclusion, and 
that this means some implementations will have to change to conform to 
the clarified spec, which we regret.

We welcome in feedback on this matter, but in the interest of publishing 
the SVG 1.1 2nd edition spec, we ask folks to respond within 2 weeks.

[1] http://lists.w3.org/Archives/Public/www-svg/2008Dec/0015.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 25 January 2010 05:10:13 UTC