Hi Thomas,
thanks for joining the discussion.
A little more info:
I am not claiming that my proposal is the right way to go forward. I was
not aware that the current behavior of Batik is useful or necessary to
many applications. The WG did not discuss the issue yet. They are still
busy with the mobile version. I only raised the issue and hope that it
will be dealt with during SVG 1.2 full or as an errata.
I can understand that you currently don't want to change Batiks behavior
while its not yet clear how this will be specified. I am sorry if you
are tired of implementing features that the WG changes frequently.
So my point of view is from a content creator and I am observing
differences in behavior within different user agents. My goal is that
all UAs behave the same.
I also re-read the sections on the <svg /> element and <clipPath />.
From my point of view the behavior is unspecified. As I understand, the
default behavior of an <svg/> element is like if the "overflow"
attribute is set to "hidden". This means that a rectangular clipPath
needs to be established by the UA. However, the clipPath definition does
not tell whether the areas outside the clipPath area are still sensitive
to events or not. Its simply not specified.
From my tests in UAs, Firefox, Opera and ASV don't appear to be
sensitive outside the clipPath area, but Batik is. Batik only seems to
clip the visual part.
So how would you solve my problem currently and how would you suggest
that the spec should be changed to address the problem?
Should we have an additional value for pointer-events as you suggested?
Or would one of the existing pointer-events value do the job? Or should
we describe in more detail how the clipPath works or add an additional
attribute there?
Other question:
Given this simple file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd";>
<svg xmlns="http://www.w3.org/2000/svg"; width="100%" height="100%"
viewBox="0 0 1000 700">
<desc>clippath event sensitivity test </desc>
<defs>
<clipPath id="clipTest">
<rect x="300" y="200" width="300" height="200" />
</clipPath>
</defs>
<rect x="-1000" y="-1000" width="5000" height="5000" fill="red"
onclick="alert('test')" clip-path="url(#clipTest)" />
</svg>
how can I restrict the "onclick" event sensitivity to the clipped area
in Batik?
Thank you for helping to find a solution for my problem.
Andreas
[EMAIL PROTECTED] wrote:
Hi Andreas,
Andreas Neumann <[EMAIL PROTECTED]> wrote on 10/11/2006 11:54:46
AM:
Now with Batik's current behavior, if the content of "map2", which is
hierarchically higher in the tree, is a lot bigger than the specified
viewBox (which is typical in many mapping or other applications) then
"map1" won't receive any events, because the invisible content of
"map2", although not visible, still receives the events because it
overlaps content of "map1".
While I agree the above is a problem, I don't particularly
agree with your proposed solution.
The viewBox is from a spec and rendering perspective
nothing special it is just a clip operation, and one that can be
turned off with the overflow property.
In SVG there are already many cases where non-visible elements
receive events, and this behavior is controlled via the
pointer-events property.
If the WG wants to add clipping to the list of attributes that
pointer-events can adjust then that might make sense.
Additionally, it is worth noting that the 'non-clipping'
behavior is actually very useful in more 'application' contexts
as it allows the user to drag objects on the canvas much more
naturally (if the cursor leaves the window it can still be
tracked by the canvas). This is perhaps more important for
Batik than most SVG implementations...
If the WG adds required clipping of events to the viewBox
then it should also add some form of mouse event grab facility
so that dragging can still work correctly.
I know that the behavior isn't specified in the SVG 1.1 spec, but I
raised an issue with the SVG WG and they will address this in the SVG
1.2 full or an SVG 1.1 errata. I examined this behavior in other SVG 1.1
full viewers. Here is the result:
I think the proposed solution is incomplete and likely
to need some significant modifications/additions before being
adopted into the spec.
While I can't speak for Cameron, I'm a tired of implementing
features and having the WG change them later, so I don't have
much interest in implementing the proposed change. Sorry.
* ASV isn't sensitive outside the specified viewBox (it hadn't been for
years)
* Opera9 initially behaved like Batik, but changed the behaviour after I
contacted them, prior to the official version 9 release
* Firefox: FF1.5 and FF2 beta behave like Batik today, however there is
a patch now for the trunk version (FF3) and I hope that this patch will
eventually make it into FF2 final to align the behavior with ASV and
Opera9
What is your opinion on this? Are you able to provide a fix for this
behavior as well, even if it isn't (yet) specified in the current spec?
Thank you for discussing this problem and maybe considering patching
Batik's behavior.
Andreas
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: [EMAIL PROTECTED]
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
