4

Consider this simple SVG file:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:x="http://www.w3.org/1999/xlink"
     viewBox="0 0 353 150">
  <defs>
    <clipPath id="walk0"><rect width="44" height="70" /></clipPath>
    <image id="img" x:href="http://phrogz.net/tmp/walking-girl2.png"
           width="353" height="70" />
  </defs>
  <use x:href="#img"        clip-path="url(#walk0)" />
  <use x:href="#img" y="80" clip-path="url(#walk0)" />
</svg>

The intent is to have two copies of the spritesheet clipped to the same region, with the second copy 80 units lower down. This works as intended in Firefox (the clipping path is applied before the y offset). In Chrome and Safari, however, the second image is not shown. (The clipping path is applied using global SVG unit space, and hence shows an empty area of the image.)

                            Two girls seen in Firefox; only one seen in Chrome

1) Which one of these browsers is correct?, or
2) What is the simplest, standards-based way to achieve this goal?

I can work around the problem by using wrapping <g> elements with transforms; this works in both Firefox and Chrome. But I'm hoping that there's a simpler way to achieve the same results in a correct and cross-browser manner.

FWIW, I also tried setting clipPathUnits="objectBoundingBox" on the clipPath, but this always produced an unclipped image. This was true even when I wrapped the <image> in a <symbol> with an explicit viewBox, height and width and referenced that with the <use> instead of the <image>. Either I don't understand how objectBoundingBox is supposed to work, or support for it is currently broken. It is certainly possible that the answer is the former instead of the latter. ;)

Phrogz
  • 296,393
  • 112
  • 651
  • 745
  • Opera displays one image, like Safari. Probably worth raising a bug in [bugzilla](https://bugzilla.mozilla.org) so we can look into it in more detail since it's most likely a Firefox issue. – Robert Longson Feb 24 '12 at 06:34

1 Answers1

3

The easiest, standards-compliant way to differentiate between these is to use the SVG test suite provided by W3.org. This suite provides tests for use structs that you can play with to determine compliance, among many others.

The problem is how your y value is being parsed, which is causing your figure to translate out of the second frame, but only in some browsers. This is the correct, cross-browser way to specify the desired translation:

<use x:href="#img" clip-path="url(#walk0)"transform="translate(0,80)"/>

I would assume the dubious parsing with respect to the current clipping pane is a regression.

MrGomez
  • 23,788
  • 45
  • 72
  • Those tests I referenced fail in my version of Chrome, by the way. And yes, I only see one copy of the image. – MrGomez Mar 23 '12 at 04:43
  • Great information. Note that if you use a less-transformed `` a portion of the original shows up. So the question is not whether it is being cloned—it is—but rather what is the correct coordinate system within which the clipping path should be calculated. – Phrogz Mar 23 '12 at 05:14
  • Ah! That's quite interesting. See [the coords examples](http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/index.html) provided, then. Since you're in a better position than I to test all three browsers (I'm constrained to Firefox and Chrome at the moment), any regressions here should be notable. I especially suspect [this](http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/coords-units-03-b.html) may fail. – MrGomez Mar 23 '12 at 05:24
  • Nailed it. Please see if my edit resolves your second quandary. – MrGomez Mar 23 '12 at 06:14
  • Looks promising; using the `transform` does work in Safari, Chrome, Opera, Firefox, and IE. One question, though: to which section of the 570k errata are you referring? – Phrogz Mar 23 '12 at 06:24
  • @Phrogz Valid point. That was me dubiously trying to get out of the trouble of properly editing my answer. I've tersified the answer, limiting it to just the information that's relevant, and removed the dubious errata pointer. :) – MrGomez Mar 23 '12 at 06:25
  • 1
    Nice. Winner winner, chicken dinner, you get the bounty. I'd still love to know what the "correct" behavior is for `y` in that context, but perhaps that will resolve itself in the dueling bug reports I'll file with Webkit and then perhaps Mozilla. :) – Phrogz Mar 23 '12 at 06:27