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

Hi Doug,

As per my ACTION-2365 [1], I've added the proposed wording to the Errata [2] and 
fixed the typos. We should review this item at the next telephone conference.

This closes my action.

Thanks,

Anthony

[1] http://www.w3.org/Graphics/SVG/WG/track/actions/2365
[2] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#clippath-pointer-events

Doug Schepers wrote:
> 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 Tuesday, 2 December 2008 23:11:39 UTC