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 <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> 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" <yishayj...@hotmail.com> 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
>>>
>>>
>>
>>
>>
>
>
>
