This looks ok to me. As I understand it [1] the only difference between position: static (which is the default) and position: relative is that they don’t obey left, top, bottom, right rules. Since Royale won’t be injecting unintended offset values, the default behavior shouldn’t change.
[1] https://stackoverflow.com/questions/5011211/difference-between-static-and-relative-positioning ________________________________ From: Harbs <[email protected]> Sent: Monday, June 4, 2018 11:55:52 PM To: [email protected] Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix? Sorry I was a bit confused. The selector that works is: .Application * { position: relative; } > On Jun 4, 2018, at 11:32 PM, Harbs <[email protected]> wrote: > > Yes. But it cascades down. > > I manually made this change to the TreeExample project, and it fixed the bug. > >> On Jun 4, 2018, at 7:22 PM, Alex Harui <[email protected]> wrote: >> >> I'm still not understanding. Style.position is not inheriting so how would >> it cascade down? Isn't .Application only applied to the <body/>? >> >> Thanks, >> -Alex >> >> On 6/4/18, 9:15 AM, "Harbs" <[email protected]> wrote: >> >> I’m suggesting that we change defaults.css >> >> from: >> Application >> { >> padding: 0px; >> margin: 0px; >> } >> >> to: >> Application >> { >> padding: 0px; >> margin: 0px; >> position: relative; >> } >> >> I believe this will resolve this issue as the default would cascade down >> to all sub-elements. The default would be relative, but beads would be free >> to change that to whatever they want. >> >> Of course, that would dictate that UIBase belongs in Basic and not Core… >> ;-) >> >> Harbs >> >>> On Jun 4, 2018, at 7:10 PM, Alex Harui <[email protected]> wrote: >>> >>> I’m not sure exactly what change you are proposing, but UIBase used to set >>> position=relative on all positioners. We took that away so that the "flex" >>> and other display/layout styles would not have to deal with the excess >>> clutter and overhead of having set position on so many elements in the DOM. >>> Via PAYG, only the elements that need to have a style.position should have >>> it set. >>> >>> My 2 cents, >>> -Alex >>> >>> On 6/4/18, 8:44 AM, "Harbs" <[email protected]> wrote: >>> >>> It just occurred to me that the problem is due to the default position >>> being static. >>> >>> I just added position: relative; to the .Application css and that resolved >>> the issue as well. >>> >>> I wonder if we could completely do away with the offsetParent logic in >>> UIBase if we make the default position: relative. That would have a major >>> positive impact on performance. >>> >>> Thoughts? >>> Harbs >>> >>>> On Jun 4, 2018, at 6:36 PM, Alex Harui <[email protected]> wrote: >>>> >>>> Hi Yishay, >>>> >>>> IMO, the new fix is better. And you took the right approach by examining >>>> the code flow in the debugger. When layout fails for what appears to be a >>>> timing issue (in this case, offsetParent not set), we definitely want to >>>> take the time to carefully analyze why there is a timing issue instead of >>>> apply code to work around the current lifecycle. >>>> >>>> I'm not sure we can recommend a general pattern for layouts. I think >>>> there is some PAYG involved. It could be that in some cases the View >>>> should be responsible for setting style.position. Then the layouts don't >>>> have to spend the time verifying style.position. In other cases the >>>> layouts could be used in places where other potential layouts don't rely >>>> on style.position being a particular value. I think BasicLayout for >>>> Containers is an example. >>>> >>>> The code you used could be put into a utility function for layouts to use >>>> to guarantee that x,y will work as expected. >>>> >>>> Thanks, >>>> -Alex >>>> >>>> On 6/4/18, 8:22 AM, "yishayw" <[email protected]> wrote: >>>> >>>> Looking at it some more it has nothing to do with data binding. I pushed a >>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the >>>> layout itself. Here it's assumed the offsetParent is explicitly set before >>>> children's x and y are set. Should this be a general pattern? >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: >>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981&sdata=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D&reserved=0 >>>> >>>> >>> >>> >>> >> >> >> >
