W3C home > Mailing lists > Public > www-svg@w3.org > January 2010

Re: getBBox() on a <use>

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 20 Jan 2010 15:45:07 -0500
Message-ID: <4B576B53.30209@mit.edu>
To: Dirk Schulze <vbs85@gmx.de>
CC: www-svg <www-svg@w3.org>
On 1/20/10 7:48 AM, Dirk Schulze wrote:
> I don't know the correct behavior of getBbox, but it sound a bit
> strange, that the bbox should be the bbox of the rect? The rect isn't
> placed at 100,100 on applying the <use> coordinates

100,100 in which coordinate system?

getBBox says that it works in user coordinates of the node it's called 
on in SVG 1.1.  The transform attribute creates a new user coordinate 
system.  If the language of 
http://www.w3.org/TR/SVG11/struct.html#UseElement about "A 'use' element 
has the same visual effect as if the 'use' element were replaced by the 
following generated content:" is taken at face value, then Jeff's 
testcase should have behavior equivalent to:

<svg xmlns="http://www.w3.org/2000/svg"
   <rect id="r" x="100" y="100" width="200" height="100" fill="red" />
   <g transform="translate(200, 200)" id="u">
     <rect id="r" x="100" y="100" width="200" height="100" fill="red" />

         var u = document.getElementById("u"),
             b = u.getBBox();

All three of Webkit, Gecko, Opera claim a bbox of 100,100,200,100 in 
this case, which seems to be what SVG 1.1 calls for.

For the <use> case Jeff posted it looks like Webkit doesn't treat the 
<use> itself as establishing new user coordinate system (or at least 
doesn't have the 200,200 offset accounted for in the user coordinates of 
the <use>).  I can't tell you whether that's actually correct per spec 
or not; it all depends on how much of the struct.html#UseElement text 
actually means to say what it says.

> That would mean, that the bbox is not very helpful on a use element,
> since it doesn't have any relation to the real position of it or it's
> content?

"Real" in which coordinate system?

Received on Wednesday, 20 January 2010 20:45:42 UTC

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