You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Andreas Neumann <ne...@karto.baug.ethz.ch> on 2006/10/11 17:54:46 UTC
event sensitivity in nested svgs when content is bigger than viewBox
Hi Thomas and Cameron,
A long time ago (several months/years) I started discussing this issue
(can't remember where it is in the archives). I would like to restart
this discussion again and hope that you can find a solution for my problem.
Here is the problem:
there are two or more <svg/> elements nested into a parent <svg/>
element, just like the following structure:
<svg viewBox="0 0 1000 700">
<svg id="map1" x="10" y="10" width="300" height="300"
viewBox="600000 200000 100000 100000">
<!-- some map content that is bigger than the specified viewBox -->
</svg>
<svg id="map2" x="320" y="10" width="300" height="300"
viewBox="600000 200000 100000 100000">
<!-- some map content that is bigger than the specified viewBox -->
</svg>
<!-- and maybe a third, fourth or fifth svg element -->
</svg>
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".
Here are two examples illustrating the problem:
http://www.carto.net/papers/svg/gui/scrollbar/index.svg
The two images are bigger than the viewBox of the two nested <svg/>
elements. If the lower images (which is hierarchically higher than the
upper image) is panned such that parts of the image overlap with the
upper image, the upper image doesn't receive any events.
http://www.carto.net/papers/svg/navTools2/index.svg (still a buggy
prototype)
If you display 2 to 4 maps (change with the selectionLists) there is a
big mess if the contents of the adjacent <svg/> elements overlap.
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:
* 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: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: event sensitivity in nested svgs when content is bigger than viewBox
Posted by th...@kodak.com.
Hi Andreas,
Andreas Neumann <ne...@karto.baug.ethz.ch> wrote on 10/12/2006 09:29:02
AM:
> A little more info:
> 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.
Did you re-read the sections on Interactivity and pointer-events?
When I read that, it clearly states that an element should be the focus
of events when the cursor is over the interior and/or stroke +
visibility/painting of the element (depending on the current setting).
It makes no mention of clip/view ports interacting with this
interior detection (it does mention that 'display' should make an
element ineligible for events, so some attention was paid to things
that should turn events off). I will grant you that it also doesn't
explicitly state that clipping doesn't effect it (it also fails to
mention masking, filters, patterns, etc that might create similar
effects).
> 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.
I agree that the spec is a bit ambiguous but since the section
that describes what is sensitive to pointer-events fails to mention
clip having any effect, my leaning is towards saying that it shouldn't.
> 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.
We've been the only U/A to do things properly according to the
spec before. ;)
> 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?
My leaning would be towards either extending the pointer-events
property or adding an additional property that controlled if clipping
also clipped event sensitivity (probably evaluated on the clipping
element). Something like clip-pointer-events="(true|false)".
> Other question:
>
> Given this simple file: [...]
>
> how can I restrict the "onclick" event sensitivity to the clipped area
> in Batik?
The short answer is you can't. As I read it the SVG spec doesn't
allow you to ;) The longer answer is that with script you could
essentially do your own event management with a glass pane and the
intersection functions, then construct your own click event and dispatch
it into the DOM. Doing this would of course be a real pain.
I never said you didn't have a legitimate problem. I just
don't like it when problems in the spec are "fixed" with errata
that make substantive modifications to existing features. Especially
when that fix breaks something that is actually useful in some cases.
> Thank you for helping to find a solution for my problem.
>
> Andreas
>
>
> thomas.deweese@kodak.com wrote:
>
> >Hi Andreas,
> >
> >Andreas Neumann <ne...@karto.baug.ethz.ch> 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: neumann@karto.baug.ethz.ch
> www: http://www.carto.net/neumann/
> SVG.Open: http://www.svgopen.org/
> Carto.net: http://www.carto.net/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: event sensitivity in nested svgs when content is bigger than
viewBox
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
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
thomas.deweese@kodak.com wrote:
>Hi Andreas,
>
>Andreas Neumann <ne...@karto.baug.ethz.ch> 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: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: event sensitivity in nested svgs when content is bigger than viewBox
Posted by th...@kodak.com.
Hi Andreas,
Andreas Neumann <ne...@karto.baug.ethz.ch> 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: neumann@karto.baug.ethz.ch
> www: http://www.carto.net/neumann/
> SVG.Open: http://www.svgopen.org/
> Carto.net: http://www.carto.net/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org