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

Fwd: getBBox() on a <use>

From: Jeff Schiller <codedread@gmail.com>
Date: Wed, 20 Jan 2010 14:47:52 -0600
Message-ID: <da131fde1001201247x7921d3d2gba52e26b764f5f67@mail.gmail.com>
To: www-svg <www-svg@w3.org>
In order to maximize confusion, I inadvertently did not CC the www-svg
mailing list on this.

Jeff


---------- Forwarded message ----------
From: Jeff Schiller <codedread@gmail.com>
Date: Wed, Jan 20, 2010 at 12:06 AM
Subject: Re: getBBox() on a <use>
To: Boris Zbarsky <bzbarsky@mit.edu>


Boris,

Actually Batik also has the same result.

The confusing part is that <g> does not have x,y,width,height
attributes, while <use> does, implying that the <use> imposes a given
box in the user coordinate system beyond just its referenced/shadowed
content.

I realize that it's too late to change things in SVG 1.1 and SVGT 1.2,
but I'm curious why would it be useful for getBBox() on a <use>
element to return the bounding box of the referenced content and not
take into account the position/scaling imposed by the surrounding use
element's x,y,width,height?

For instance, I could have six <use> elements all pointing to the same
element - yet all six <use> bboxes would be identical.

Thanks,
Jeff

On Tue, Jan 19, 2010 at 11:09 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/19/10 10:25 PM, Jeff Schiller wrote:
>>
>> In other words, shouldn't the bbox of a<use>  element be defined by
>> its x,y,width,height just like a<rect>  or an<image>  ?  No browser
>> gives consistent results:
>>
>> Firefox  :  100, 100, 200, 100
>> Opera   :  100, 100, 200, 100
>
> Those seem somewhat consistent to me.... ;)
>
>
>> WebKit :   300, 300, 200, 100 (huh? clearly a bug!)
>>
>> What's ASV do?
>> What's IE9 do? :)
>
> Here's what SVG 1.1 currently says (at
> http://www.w3.org/TR/SVG11/types.html#InterfaceSVGLocatable ):
>
>  getBBox
>     Returns the tight bounding box in current user space (i.e.,
>     after application of the transform attribute, if any) on the
>     geometry of all contained graphics elements, exclusive of
>     stroke-width and filter effects).
>
> Note that this is subtly different from what SVG Tiny 1.2 uDOM says (at
> http://www.w3.org/TR/SVGMobile12/coords.html#BoundingBox ):
>
>  The bounding box (or "bbox") of an element is the tightest fitting
>  rectangle aligned with the axes of that element's user coordinate
>  system  that entirely encloses it and its descendants.
>
> Looks to me like Gecko and Opera are implementing what SVG 1.1 says.
>
> That said, what would you expect to see if you used <g> instead of <use>?
>  http://www.w3.org/TR/SVG/struct.html#UseElement has this to say:
>
>  A 'use' element has the same visual effect as if the 'use' element
>  were replaced by the following generated content:
>
> ...
>
>  # Otherwise:
>    In the generated content, the 'use' will be replaced by 'g',
>    where all attributes from the 'use' element except for x, y,
>    width, height and xlink:href are transferred to the generated
>   'g' element. An additional transformation translate(x,y) is
>    appended to the end (i.e., right-side) of the transform
>    attribute on the generated 'g', where x and y represent the
>    values of the x and y attributes on the 'use' element.
>
> whatever that means in terms of DOM APIs, since this is talking about
> "visual effect"...
>
> I agree that things are not exactly clear here.
>
> -Boris
>
Received on Wednesday, 20 January 2010 20:48:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:44 GMT