I was thinking about more as well. I agree that for the use cases you mention with regards to charts, the <g> element would be ideal:
https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g It is the recommended way to contain a group of objects. One advantage <g> over a nested <svg> is that you can apply transforms to <g> which applies to all child elements, whereas you cannot do that with a (nested) <svg> Also, fills and strokes applied to the <g> element will get inherited by the contained child shapes. Obviously, the style properties cascade, so you can override individual shapes' styles as needed. As I am typing it, I realize that this is somewhat similar to the <Group> element in FXG. We should be easily able to extend this concept in FlexJS. Thanks, Om On Wed, Sep 24, 2014 at 10:24 AM, Peter Ent <[email protected]> wrote: > Hi, > > I had a discussion with Alex about the FlexJS chart package and how it > makes use of SVG. For a quick background, the FlexJS chart package makes > use of the core.graphics package created by Om which makes FlexJS charts > much more easily cross-compiled from ActionScript to JavaScript. > > At the moment, the chart package creates a complex display list structure > where each value to be plotted is a FlexJS component/element. In > JavaScript, this comes down to a <div> with an <svg> (+ graphic, e.g., > rectangle) for each item to be rendered to display the chart. Imagine you > are plotting a lot of points (say 500). That would lead to 500 divs and > more svgs. While feasible, it takes time to render and bloats the DOM. > > Om added some efficiencies by creating a GraphicsContainer (and single > <svg>) and you can draw directly into it (have <rect>, <path>, etc.). I > modified the FlexJS chart package to take advantage of this so that each > item to be rendered makes use of the shared GraphicsContainer as its > background and adds the necessary <rect>, <path> or whatever to draw the > chart. Much more efficient. > > Since then, I've been looking deeper into SVG and discovered some things I > didn't know it was capable of (although I'm not sure how compatible they > are with IE). For example, you can nest <svg> elements and even group them. > This enables relative placement of the items. For example, right now to > draw anything, all of the coordinates are based on the (0,0) of the shared > GraphicsContainer. Meaning, each bar of a bar chart is placed relative to > the underlying chart base (<svg>). That might sound OK, which it did to me, > but after chatting with Alex, I can see that having more relative > coordinates would allow for future things such as animations. > > Consider a bar chart with two series. Right now, all of the bars are drawn > relative to the <svg>. What if each series were its own <svg>, enabling > each bar to be relative to its series origin? This would allow each series > to be manipulated independently. Further, an SVG group could be used for > all of the bars in the chart, giving them shared characteristics (color) > and that could be changed all at once by changing the group color. > > Basically, using containers within SVG will make manipulating the charts > easier in the future and there are several ways to do. I am looking for any > suggestions or thoughts folks might have who are more familiar with SVG > than I am. > > Regards, > Peter Ent > Adobe Systems >
