W3C home > Mailing lists > Public > www-svg@w3.org > November 2011

Request for explaining/interpreting clipping for <use> element

From: Rafał Miłecki <zajec5@gmail.com>
Date: Mon, 21 Nov 2011 00:02:14 +0100
Message-ID: <CACna6rwD=Yu0FmiU=5wFa1_m8jEYycH24TNov72mGA31Lnsjsw@mail.gmail.com>
To: www-svg@w3.org

I'm trying to use <use> element [0] in my project and I've noticed
cross-browsers problem when using clip-path attribute for <use>.

The problem is shown by the following code:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
<svg width="800" height="600" xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
		<image id="image" height="200" width="200" xlink:href="image.png" />
		<clipPath id="clip">
			<rect x="100" y="100" width="100" height="100" />
	<use x="100" y="100" xlink:href="#image" clip-path="url(#clip)" />

Browsers treat coordinates used in clip path differently.

1) Firefox 7, Firefox 8, Opera 11.52, Interner Explorer 9
That group of browsers takes coordinates of clip path as relative to
the <use> element (which is placed at x=100 y=100). As the result clip
path is:
a) starting at (100, 100) in relative to <use>
b) starting at (200, 200) in relation to <svg>
The result is that we you can see bottom right part of the image.png.

2) Google Chrome 15 and Opera 11.60 beta
They are treating coordinates of clip path as relative to the <svg>
root element. The clip path is:
a) starting at (0, 0) in relation to <use>
b) starting at (100, 100) in relation to <svg>
This results in visible top left part of the image.png

Could you tell me, which behavior is the correct one?

I've tried reading specs [1] [2], but I'm not sure about the correct
rendering of that case. Some help in interpretation would be nice.

[0] http://www.w3.org/TR/SVG/struct.html#UseElement
[1] http://www.w3.org/TR/SVG/masking.html#ClippingPaths
[2] http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports

Received on Monday, 21 November 2011 07:48:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:33 UTC