Loading ...
Sorry, an error occurred while loading the content.

Re: [svg-developers] Re: viewport problem in Batik and mozSVG

Expand Messages
  • Thomas DeWeese
    ... Well, I can see both sides of the issue. On the one hand an SVG element s clip is defined by the spec as a simple clip. I don t think a clip-path should
    Message 1 of 4 , Jan 29, 2005
    • 0 Attachment
      Heiko Niemann wrote:

      > I think the events should be clipped (or at least it should be an
      > option among others). For me that is the whole idea having
      > viewports.

      Well, I can see both sides of the issue. On the one hand
      an SVG element's clip is defined by the spec as a 'simple' clip.
      I don't think a clip-path should effect events, mostly because
      if it does there are lots of other effects that should effect events
      (filters, and masks to name two). On the other hand I could
      see an exception for SVG elements, but that is clearly not in
      the current SVG specification.

      > In the previous sample I could have done a workaround but
      > here is a sample where I don't see a solution not having the events
      > clipped (just think of having two maps with tooltips next to each
      > other ...):

      The solution is fairly clear you need a piece of geometry
      to 'soak up' events outside of the clip area - so it will be
      a rectangle with a hole around the clip. Put it as the last
      thing in the SVG element and set it's pointer-events to all,
      and visibility to hidden (or not it really doesn't matter).
      The new piece of geometry will get all events outside the clip
      but events will be delivered 'as normal' inside the clip.

      > you say 'in fact I have written examples that make use of this lack
      > of clipping in Batik'. Could you please provide one of these
      > examples. I think if there is use/need for both then this part of
      > the spec might need to be modified.

      It's nothing earth shattering but for most 'drag' operations
      or pointer tracking you want it to work even if the mouse goes
      outside of the viewport (which might not be the entire SVG content
      area). So for example when people drag things and they want to get
      towards the edges they often overshoot - I wanted to clip the content
      but 'keep the drag going'. As in your case I could have done it
      differently but in my case it was the simplest thing to do.

      As far as modifying the specification that is fine for SVG 1.2
      but there is just _one_ correct behavior for SVG 1.0-1.1.
    Your message has been successfully submitted and would be delivered to recipients shortly.