Maybe we need a big refactor. Things like effects are pretty advanced and maybe they should get coupled with more advanced/complex layouts that are in a different package than HTML.
The basic packages could be simpler layouts that do minimal settings. The HTML package could be JS only and just wrap the HTML elements for use with ActionScript. Then another pancake has the SWF and JS components and beads with light layouts and accessories. This seems more PAYG. Peter > On Feb 25, 2017, at 1:46 AM, Alex Harui <aha...@adobe.com> wrote: > > > >> On 2/24/17, 10:37 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote: >> >> One more thing to consider is how effects will fit in here. I can imagine >> scenarios where items inside of a container need to have an effect >> applied to them. Currently, the move effect relies on changing x, y >> values, which implies absolute positioning. If they’re all part of a >> flexbox I’m not sure how effects would apply. >> >> >> >> I ran into these issues when implementing LayoutTweener and >> EasyCollapseBead for the Accordion component. >> >> >> >> If we’re serious about having swf feature parity, I think we’ll end up >> doing everything with absolute positioning on the swf side anyway, so we >> might as well implement it the same way on the JS side. The only downside >> to this that I see is possible performance issues. >> >> >> >> What are your thoughts on this? > > That's a valid approach, but I'd much rather let the browser do the work > and try to emulate that in the SWF. Leveraging the browser should result > in smaller faster applications. However, if it turns out to do anything > reasonably "nice" in JS requires absolute positioning then, sure it may be > time to give up on the browser and write the code once to run in both SWF > and JS. > > It isn't wrong to have both choices so folks can use the browser when it > works for them and switch to a fatter/slower but perfect- > across-all-browsers version if needed. > > My 2 cents, > -Alex >
