On Jul 26, 2016 11:47 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > I agree there should be a Group object. > > The problem is that the way the classes are currently constructed is that 100 pixel “Rect" positioned at 100,100 actually contains the following markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100” height=“100”/></svg> > > I think the reason it was done this way was to make it possible to add Rects (and similar) directly to HTML elements.
Yes, that is correct. This was the intention. The idea comes from the paradigm in Flex where you can simply add a Line or Rect in any component and expect it to work correctly, especially with the layout restrictions of the parent component. You dont add a GraphicContainer or some such container to add a graphic element. This is how Spark skins are possible. > > I suppose we could change the way the classes are setup (and drawn) so that <rect> <circle> and the like could only be added to elements which legally can contain them (such as <svg> and <g>). I did toy around with this idea. How would this square when you want to draw a circle with Canvas? Might get complicated to the user. I am all for adding an SVGContainer component that expects children to be relatively positioned inside it. Maybe we could call the primitives SVGLine, SVGRect etc? And a similar setup for Canvas? Thanks, Om > > On Jul 26, 2016, at 8:38 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 7/26/16, 8:19 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > >> Both. > >> > >> In SVG we're actually struggling with the same (or rather similar) issue. > >> > >> There’s a big difference between: > >> <div><svg><rect/></svg><svg><circle/></svg></div> > >> > >> and > >> <div><svg><g><rect/><circle/></g></svg></div> > >> > >> Each svg has its own coordinate space, and svg elements cannot have > >> transform properties. This is proving to be quite difficult in terms of > >> transformations. > >> > >> Ideally, it should be easy to pick whether you want to wrap each shape in > >> its own SVG element or have them all in the same svg element (or g > >> element). Currently GraphicShape draws each shape with its own svg > >> wrapper. CompoundShape, on the other hand, draws separate objects within > >> a single svg element. GraphicContainer takes svg-type elements as > >> children, but does not care exactly which type. > >> > >> I think there should also be a GraphicGroup object which would be a g > >> element and take children. > >> > >> I’m struggling with how to specify whether svg element have the svg > >> wrapper and not. (Ideas welcome!) > > > > IMO, I suspect there exist SVG snippets in the world that folks might want > > to repurpose into their FlexJS apps. Having a simple 1:1 mapping between > > tags is probably the best strategy. Are folks worried about the overhead > > of that verbosity? IMO, it is always possible to provide aggregations, > > but aggregations make assumptions and often someone will come back and ask > > for the low-level. > > > > For example, in Flex Spark (and FlexJS) specifying a layout for a > > container takes 3 lines: > > > > <Container> > > <layout> > > <VerticalLayout /> > > </layout> > > </Container> > > > > In Flex MX, it is one line: > > > > <Container layout="Vertical" /> > > > > The problem is that you can't specify other properties on the > > VerticalLayout in MX, and Horizontal and Absolute layout are baked into > > the MX container and are linked into your code, and you can't add new > > layouts. > > > > So for graphics, if I understand the issue, why not add a <g> or <Group> > > tag and make folks use it where they need it? > > > > My 2 cents, > > -Alex >
