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]

Reply via email to