- From: Francis Hemsher <fhemsher@gmail.com>
- Date: Sun, 21 Feb 2010 14:35:01 -0500
- To: Jeff Schiller <codedread@gmail.com>
- Cc: Robert Longson <longsonr@gmail.com>, www-svg@w3.org
The <svg> element has many, many applications as a symbol where the element can be uniquely sized(width/height) and placed(x,y) within various documents: Assume a symbol library containing svg elements that are called by many apps. This is in lieu of a symbol+use pairing. There is definetly a need to be able to provide transforms to the svg element when used in this manner. Regards, Francis Hemsher On 2/21/10, Jeff Schiller <codedread@gmail.com> wrote: > No, it's not really a hardship :) > > It just seems that, if the <svg>'s x,y values are ignored when it's at > the top-level, the @transform could also similarly be ignored. > > It just seemed like an arbitrary choice that I was curious about - the > <svg> element is the only SVG element that doesn't have a transform > attribute which means special processing in the JS. > > Furthermore, it's an extra interface in the DOM that would not have > been necessary (SVGLocatable and SVGTransformable could have been > collapsed). > > Jeff > > On Sun, Feb 21, 2010 at 6:38 AM, Robert Longson <longsonr@gmail.com> wrote: >> Jeff, >> >> Perhaps because the outer SVG often has to fit inside some kind of >> rectangular space e.g. an embed or object or browser window. I don't think >> adding a <g> is so much of a hardship really is it? >> >> Best regards >> >> Robert. >> > >
Received on Sunday, 21 February 2010 19:35:33 UTC