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

Hi Doug,
Your proposal sounds good to me. Great job thinking through all of the
complexities.

In my mind, 'visiblePainted' would not accept pointer events over the parts
of the picture which were made invisible by clipping. Clipping is a
property on the graphics object just like fill and stroke. If fill:none,
then no pointer events over the interior. However, I would suggest that the
spec say SHOULD take clipping into account for pointer-events, not MUST.
For some (most? all?) user agents, clipping might be done at the device
pixel level or by clipping by converting into a mask, rather than clipping
at the geometry level. How hard is the path geometry math, how easy is it
to find the algorithms, and how much code is needed to do geometric
clipping?

I agree with using the whole glyph area for text. Did you mentioned dash
patterns? It would be ridiculous to say pointer events were not active over
the undrawn portion of a dashed stroke. Masking and opacity, however,
should have no impact on pointer-events. They don't change the visible area
from a geometric perspective.

Jon

PS. Might be good to find the idiot who came up with 'pointer-events' and
slap him around a bit.


From: Doug Schepers <schepers@w3.org>
Date: Mon, 25 Jan 2010 00:10:10 -0500
Message-ID: <4B5D27B2.3050206@w3.org>
To: www-svg <.www-svg@w3.org>
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