Hi Alex, maybe is difficult to change that now, since this refactor will imply many changes in other components and apps. In the other hand, as you said in flex we found most of the times setting both vars in mxml or in bindings, so I don't think is good to mimic this behavior. I think current one is the most used and is ok for me, since is 99% of the cases (or I never need "visibility" until yesterday).
So I think we should instead have a bead for visibility, since this is the edge case. We can even create another bead for the flex behavior, so people wanting to have the same can use both. IOW, I think we should stick with what we have, since seems what most of the people uses most of the time, but have beads for the edge cases and flex cases, since seems more PAYG. thoughts? just my 2 El lun., 8 abr. 2019 a las 3:45, Alex Harui (<aha...@adobe.com.invalid>) escribió: > Interesting. I didn't know about CSS visibility. It might be better to > have UIBase "visible" getter/setter affect CSS visibility instead of > display:none. I think it would save some code in UIBase and give us the > same effect in both Flash and browser. IncludeInLayout could be > implemented as a bead and affect display:none. I wonder how many people > truly need to exclude elements from the layout. IMO, the IncludeInLayout > property was abused in Flex to simulate navigators with deferred > instantiation and resulted in tons of performance issues. > > Thoughts? > -Alex > > On 4/7/19, 5:50 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > @Harbs, > > in the following video, > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FApacheRoyale%2Fstatus%2F1115026909363093511&data=02%7C01%7Caharui%40adobe.com%7C0ce85b87aca64b8fe20108d6bbbc323e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636902814342140692&sdata=WuElzaDSOomx1jPyQqoV0lhk0zXGtqiT5ftbmZVColA%3D&reserved=0 > > buttons are using visibility css property instead of display css > property > change. If I use display, the changes in content width will make the > slide > effect look worse. So this is a special case. > > just to show you a concrete visual case > > thanks > > > > > El lun., 8 abr. 2019 a las 0:41, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > Right, I prefer the actual "visible", just saying that I found a case > > where I need just make the artifact invisible, while it maintains > the space > > occupied > > > > Maybe this is 1% of cases, but I think we need a bead just to handle > > "visibility" css property in Royale from AS3. I don't think this > should > > mimic flex since we end always setting two properties each time what > was > > cumbersome. > > > > El lun., 8 abr. 2019 a las 0:02, Harbs (<harbs.li...@gmail.com>) > escribió: > > > >> includeInLayout actually removes the object from the structure when > not > >> included. > >> > >> I guess theoretically this can mean a simpler structure, but to me > >> visible is better because: > >> > >> 1. There’s less overhead on adding and removing. > >> 2. With includeInLayout there’s more chance of getting RTEs when the > >> element does not exist, while with visible, it exists even when not > >> computed for layout. > >> > >> > On Apr 8, 2019, at 12:27 AM, Carlos Rovira < > carlosrov...@apache.org> > >> wrote: > >> > > >> > Hi, > >> > > >> > sorry, but I invert what I want to say. We currently have: > >> > > >> > visible: this is like includeInLayout + visible in flex since it > >> changes > >> > "display" between "none" and "block" or "flex" right? > >> > if I put visible to false, display is "none", and this makes the > object > >> > disappear from screen and also don't compute in html layout, so > in flex > >> > will be like visible=false and includeInLayout= false > >> > if I put visible to true, display is "block"/"flex", and this > makes the > >> > object visible in screen and depending on things like position > compute > >> in > >> > layout, > >> > so in flex will be like visible=true and includeInLayout= true > >> > This use to be the main use we all do most of the times. > >> > > >> > in the other hand we have "visibility", that makes the object not > >> visible > >> > but included in layout (still is there occupying some space in > screen) > >> > so in flex will be like visible=true or false but > includeInLayout= true > >> > always. > >> > > >> > I found this useful under certain circumstances. For example in > Wizard > >> I'm > >> > adding transitions and navigation buttons should better maintain > the > >> space > >> > but disappear, instead of make the slide grow or shrink. So I > think this > >> > will be useful for others. > >> > > >> > Maybe since we did visible not equal to flex, now > "includeInLayout" has > >> no > >> > sense.. but still a bead for "visibility" can be useful > >> > > >> > @Piotr: don't think I understand correctly your message. You say > >> > Disable/Enable is for visibility? > >> > > >> > > >> > > >> > El dom., 7 abr. 2019 a las 16:26, Harbs (<harbs.li...@gmail.com>) > >> escribió: > >> > > >> >> Why not just use “visible”? > >> >> > >> >>> On Apr 7, 2019, at 2:15 PM, Carlos Rovira < > carlosrov...@apache.org> > >> >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> we can get flex "includedInLayout" using css "visibility" > property > >> (with > >> >>> visible/hidden) > >> >>> > >> >>> I suppose it's not in UIBase for if PAYG reasons, so I can add > it as a > >> >> bead > >> >>> if there's no other proposal. > >> >>> > >> >>> thanks > >> >>> > >> >>> -- > >> >>> Carlos Rovira > >> >>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0ce85b87aca64b8fe20108d6bbbc323e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636902814342140692&sdata=t4kfWMi8KBiNVQ%2Fw44d4bGavO%2FzqK6YtkOQcBsuds2g%3D&reserved=0 > >> >> > >> >> > >> > > >> > -- > >> > Carlos Rovira > >> > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0ce85b87aca64b8fe20108d6bbbc323e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636902814342140692&sdata=t4kfWMi8KBiNVQ%2Fw44d4bGavO%2FzqK6YtkOQcBsuds2g%3D&reserved=0 > >> > >> > > > > -- > > Carlos Rovira > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0ce85b87aca64b8fe20108d6bbbc323e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636902814342140692&sdata=t4kfWMi8KBiNVQ%2Fw44d4bGavO%2FzqK6YtkOQcBsuds2g%3D&reserved=0 > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0ce85b87aca64b8fe20108d6bbbc323e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636902814342140692&sdata=t4kfWMi8KBiNVQ%2Fw44d4bGavO%2FzqK6YtkOQcBsuds2g%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
