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

Re: Proposal: Nesting SVG Graphics Elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 30 Nov 2012 09:38:56 -0800
Message-ID: <CAAWBYDDBqnxD=hVM+fD82t26kXYNAu9xgwFtM_OHdxiri+pZ_A@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Doug Schepers <schepers@w3.org>, "steve@fenestra.com" <steve@fenestra.com>, SVG public list <www-svg@w3.org>
On Thu, Nov 29, 2012 at 11:30 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> But what about this example:
> <rect width="200" height="200">
>         <rect width="120%" height="120%"/>
> </rect>
> The bounding box of the parent is 200x200. The child element would get the size of 240x240. This means the bounding box of the parent must change to 240x240 as well. An infinite loop, or just not possible to solve.

We wouldn't use the bounding box, we'd use the actual dimensions.
(For <path> we'd use something similar, I guess - the bounding box of
the path itself, ignoring its children.  Same deal, it's just that the
box isn't immediately apparent from the <path>'s attributes like it is
for every other element.)

> But even if it is not relative to the parent size:
> <rect width="200" height="200">
>         <rect x="40" y="40" width="200" height="200"/>
> </rect>
> The dimension of the inner child element is 240x240 which affects the bounding box of the paren which used to be 200x200. We are opening the Pandora's box with it. It doesn't stop here. It has affects on masking, filters and clipping as well, which will be relative to the painting bounding box or define the painting bounding box can can collude here.

"Opening the Pandora's box" seems a bit overwrought, don't you think?
Yes, the bounding box is larger.  And?  It's equivalent to the
bounding box of a <g> wrapped around both if they were siblings.

Yes, the effects on other things that rely on bounding box would have
to be defined - whether they rely on the element's "intrinsic"
bounding box, or the bounding box with children.

Received on Friday, 30 November 2012 17:47:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:30 UTC