Thinking about this some more, I think an svg should have a different API. SVG elements should inherit from UIBase and have the full capabilities For one, I’m not sure primitives should implement beads. UIBase also makes a lot of assumptions based on normal DOM elements. SVG has quite a few attributes which can be specified directly rather than using styles (i.e. width, height opacity, etc.)
It seem to me like primitives are pretty well defined and the full gamut of behavior should be part of the classes. Any behavior beyond that should require either using proper components, or wrapping the primitives in primitive containers. Another area which makes sense to have separate APIs for primitives is related to defs.[1] You can define definitions in SVG and use those in SVG elements contained therein. There should be a mechanism for primitives to get defs of their containing SVG element. A good example is masks[2] masking content in a single SVG is straightforward, but masking one SVG using another is not. [1]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs [2]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/mask On Jul 27, 2016, at 10:59 AM, yishayw <yishayj...@hotmail.com> wrote: > I propose to have a single class. It could have a get > drawnElement():WrappedHTMLElement which the transform bead, or other > clients, would reference when interested in DOM manipulation. The condition > would be implemented once there. > > Again, this is assuming wrapping in <svg> doesn't somehow make it a > candidate for a different API. > > > > > > -- > View this message in context: > http://apache-flex-development.2333347.n4.nabble.com/Changed-svg-namespace-tp54150p54222.html > Sent from the Apache Flex Development mailing list archive at Nabble.com.
