Hi Andreas,
Andreas Neumann <[EMAIL PROTECTED]> 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
>
>
> [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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
