Re: Clipping and pointer-events erratum (ACTION-2358)

Hi, Folks-

Here is my proposed wording for pointer-events and bounding boxes for
clipping paths.  Thoughts?

<h3 id="clipPath-geometry">14.3.6 Clipping paths, geometry, and pointer
events</h3>

<p>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 <span
class="element-name">'clipPath'</span> element via a <span
class="prop-name">'clip-path'</span> property) must remain the same as
if it were not clipped.</p>

<p>With regards to <a
href="interact.html#PointerEventsProperty">pointer-events</a>, while the
visible parts of a clipped element receive pointer events normally,
parts of a clipped element which are outside the extent of the clipping
path must be treated as if they have a <span
class="prop-name">'visibility'</span> property value of <span
class="prop-value">'hidden'</span>.  Therefore, and element which has <a
href="interact.html#PointerEventsProperty"><span
class="prop-name">'pointer-events'</span></a> property values which
depend upon the visibility of the element (e.g.  <span
class="prop-name">'visiblePainted'</span>, <span
class="prop-name">'visibleFill'</span>, <span
class="prop-name">'visibleStroke'</span>, <span
class="prop-name">'visible'</span>) will not receive pointer events for
the occluded parts of the element.  For example, a circle with a radius
of 10 which is clipped to a circle with a radius of 5 will not receive
<span class="event-name">'click'</span> events outside the smaller
radius if it has the default <a
href="interact.html#PointerEventsProperty"><span
class="prop-name">'pointer-events'</span></a> property value of <span
class="prop-name">'visiblePainted'</span>, but will if has the property
value of <span class="prop-name">'all'</span>.</p>

Regards-
-Doug


Cameron McCormack wrote (on 11/25/08 6:23 PM):
> Batik would be a beneficiary of getting
> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#clippath-pointer-events
> done.
> 
> 
> ----- Forwarded message from thomas.deweese@kodak.com -----
> 
> From: thomas.deweese@kodak.com
> Date: Tue, 25 Nov 2008 06:48:46 -0500
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: Re: Likely Batik bug with SVG scrollbars
> 
> Hi John,
> 
> "John C. Turnbull" <ozemale@ozemail.com.au> wrote on 11/25/2008 02:27:51 
> AM:
> 
>> [..] open the SVG in Batik you will find that if 
>> you drag the lower image up as far as it can go and then try to use 
>> the top horizontal scroll bar, the lower image will be scrolled 
>> instead.  It seems that Batik thinks the lower image has moved over 
>> the top of the upper one which is not the case.
> 
>    Actually it has, it's just that it's drawing was clipped. 
> Last time I checked it was unclear if SVG events should respect
> clipping or not (there are arguments on both sides).
> 
>    Anyway take a look at:
>         https://issues.apache.org/bugzilla/show_bug.cgi?id=46289
> 
>> Can anyone see why this buggy behaviour is happening?  Can it be 
>> fixed?  Getting SVG scrollbars to work with Batik is critical to my 
>> current project so I really need to resolve this.
> 
>    I'm not sure it's really buggy behavior.
> 
> ----- End forwarded message -----

Received on Monday, 1 December 2008 19:47:58 UTC