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? From: Peter Ent<mailto:p...@adobe.com> Sent: Friday, February 24, 2017 9:42 PM To: dev@flex.apache.org<mailto:dev@flex.apache.org> Subject: Re: [FlexJS]Layout redux Hi, I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout that adds code for the SWF side. In general, the SWF and JS sides look the same. There are some differences which I'm working on, but these should be usable. In doing this I've uncovered some incomplete work and/or exposed some issues. These are, in no particular order: UIBase vs. IUIBase. Since some of our components do not inherit from UIBase, you cannot cast everything to this class. Now as we should really use interfaces and not classes, casting to IUIBase generally works. However, IUIBase is missing a lot of useful function prototypes which is why there is a lot of casting to UIBase. I'd like to see IUIBase become more complete. The layout code does a lot of extra, unnecessary casts on the SWF side. JS vs SWF layouts. When you think about it, once you've set up your <div> to have the property display style, adding/removing/changing elements gets taken care by the browser. If I set up my <div> with display:flex and then put in a number of elements and start changing them via JavaScript, they just change. Of course that doesn't work on the SWF side because there isn't anything to size and position elements except the layout algorithms. But the events that trigger those algorithms to execute are in the Container class which causes the layout - SWF or JS - to execute. Basically, it seems unnecessary to re-execute JS layouts every time since the browser does the work. I think this should be revisited. Padding. This still isn't working right for the Container with layout. Part of the problem is that padding on the SWF side isn't really padding. What it does it offset the inner contentArea. This was done so that when you have a Container with padding=10 and you place a child into it, the child's (x,y) reads as (0,0) and not (10,10). When I did a test with a <div> that had padding:10px, the first item in it reported left:10, top:10. So I wonder if we shouldn't treat padding the same way? Basically, I'm wondering if we should revisit the concept of container components again and nail it down. The SWF and JS platforms are very, very different here and I think we need to put more thought into it. For example, maybe layouts should be SWF only and then only to mimic what you can do with CSS. That might be too complex though. What I still need to do for the Flex layouts is handle visibility. Or more specifically, state changes. The DataBindingExample doesn't work right when the state changes. The next thing is to add just a couple of Flexbox features. Specially, I think justify-content, align-items, and align-content. Easy enough to add for JS of course. —peter On 2/23/17, 8:25 AM, "Peter Ent" <p...@adobe.com> wrote: > > >On 2/23/17, 1:54 AM, "Alex Harui" <aha...@adobe.com> wrote: > >>A few comments/questions: >> >>What does flex-box do when it runs out of room? Doesn't it wrap to a new >>row/column? Or can that be controlled? I think most folks expect >>VerticalLayout to not create a new column but to keep going vertically >>and >>be clipped or scrolled. > >Flexbox has a number of options. Wrapping is one of them but is not the >default. It set these layouts to not wrap so you get a single column or >row. I did not set overflow, but it probably should be set to hidden or >auto; trying to match up what we want the SWF side - which takes much more >effort/code to mimic - requires us to make a choice for default behavior. > >I think that using the Flexbox layout will give good results on the JS >side. I deliberately didn't add more features just to see what people >think of using it. It has some cool layout features and seems to solve a >lot of layout problems people have had using CSS. It might not be right >for all situations of course. > >> >>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites >>again. That's what the dual branch is all about. >> >>+1 for lighterweight (one div) Container. I thought we'd already done >>something like that in one of the Item Renderers. But Panel and other >>ChromContainers probably need to extend Container because people expect >>it, although I'd be fine if they both just implemented some sort of >>IContainer. >> >>As an alternative to flex-box, it is totally fine to have more than one >>VerticalLayout. One that tries to use display:block and another one that >>runs a bunch of code and does position:absolute on everything. >> >>In reality, how many of you use position:absolute or position:relative in >>a real-world HTML/JS UI? It still feels like we are going to end up >>using >>it too much, but maybe that's what has to happen in order to solve some >>of >>the common layout issues, like making one thing stretch to fill all >>available space. > >I agree. When you look at the generated HTML, there's way too much forcing >of size and position that a natural HTML author would not use. But I'm not >sure how to really do this programmatically while allowing all sorts of >situations to work. > >> >>My 2 cents, >>-Alex >> >>On 2/22/17, 2:31 PM, "Peter Ent" <p...@adobe.com> wrote: >> >>>Great. Thanks. I will take a look at these tomorrow. >>>‹peter >>> >>>On 2/22/17, 5:19 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>>This too: >>>>https://philipwalton.github.io/solved-by-flexbox/ >>>> >>>>> On Feb 23, 2017, at 12:16 AM, Harbs <harbs.li...@gmail.com> wrote: >>>>> >>>>> BTW, this might be useful: >>>>> https://github.com/philipwalton/flexbugs >>>>><https://github.com/philipwalton/flexbugs> >>>>> >>>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.li...@gmail.com >>>>>><mailto:harbs.li...@gmail.com>> wrote: >>>>>> >>>>>> How well do these work in IE? >>>>>> >>>>>> It looks like Flexbox is not supported at all in IE prior to IE10 >>>>>>and >>>>>>even in IE10 and 11, it only has buggy support.[1] >>>>>> >>>>>> [1]http://caniuse.com/#feat=flexbox >>>>>><http://caniuse.com/#feat=flexbox> >>>>>> >>>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <p...@adobe.com >>>>>>><mailto:p...@adobe.com>> wrote: >>>>>>> >>>>>>> I just pushed new layouts: VerticalFlexLayout and >>>>>>>HorizontalFlexLayout as >>>>>>> well as a change to DataBindingExample to use them. I consider >>>>>>>these >>>>>>> temporary and would like to make them be the VerticalLayout and >>>>>>> HorizontalLayout in the near future. >>>>>> >>>>> >>>> >>> >> >
