- From: Jeff Schiller <codedread@gmail.com>
- Date: Fri, 29 Jan 2010 09:30:36 -0600
- To: Francis Hemsher <fhemsher@gmail.com>
- Cc: Patrick Dengler <patd@microsoft.com>, www-svg <www-svg@w3.org>
Hi Francis, Actually you remind me to bring up a point here: In the SVG 1.1 spec [1], it shows the properties of SVGRect (x,y,width,height) and SVGMatrix (a,b,c,d,e,f) with the comment // raises DOMException on setting However, I've never seen this in practice (and actually SVG-edit really depends on the values of SVGMatrix being editable in some cases). Is this corrected in SVG 1.1 2ed? Can someone give insight into this? Thanks, Jeff [1] http://www.w3.org/TR/SVG11/idl.html On Fri, Jan 29, 2010 at 9:23 AM, Francis Hemsher <fhemsher@gmail.com> wrote: > Hi Patrick, > I've never had a need to consider changing the bounding box values. > I always assumed it was read-only. > > Regards, > Francis > > On 1/29/10, Patrick Dengler <patd@microsoft.com> wrote: >> Sorry to be the late to the game on this one, I thought I would add more >> confusion or perhaps ask an already answered question :) >> >> Should SVGLocatable.getBBox return a read-only SVGRect? >> >> You obviously cannot modify the bounding box of an element by modifying the >> rectangle. Making it readonly would allow implementations to store a cached >> result without fear of the value being changed by callers. >> >> Thanks in advance, >> >> Patrick Dengle >> >> -----Original Message----- >> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of >> Boris Zbarsky >> Sent: Wednesday, January 20, 2010 12:53 PM >> To: Jeff Schiller >> Cc: www-svg >> Subject: Re: Fwd: getBBox() on a <use> >> >> On 1/20/10 3:47 PM, Jeff Schiller wrote: >>> 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. >> >> Yep. >> >>> 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? >> >> I have no idea, honestly. But then again, the behavior of getBBox() >> generally seems to be ... somewhat odd (given the user coordinate system >> thing). >> >>> For instance, I could have six<use> elements all pointing to the same >>> element - yet all six<use> bboxes would be identical. >> >> I'm not sure they necessarily would if the element used percent sizes, >> would they? >> >> -Boris >> >> >> >> > >
Received on Friday, 29 January 2010 15:31:11 UTC