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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
