> ... and not very PAYG.
On the contrary.
The same way we are applying box-sizing: border-box because it is a better
default and prevents extra processing, applying relative instead of static as a
default allows us to make assumptions that lets us use less code.
Yes. It’s a change, but it’s one which should make the default simpler and more
PAYG.
I can do this on a branch and compile the examples. We can see how this effects
them. Does that sound like a plan?
> On Jun 6, 2018, at 6:23 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> This sounds scary to me because it affects the entire DOM, and not very PAYG.
> Maybe Carlos should try it on his Jewel layouts and see if anything breaks.
>
> Some other implementation options would be to:
>
> -Have the x,y setters set position on the parent. I think we used to do this
> and decided to not do it anymore
> -Have the x,y setters add a class selector to the parent.
> -Have a bead, like we've discussed for UnselectableElement, that brings in
> the selector.
> -Have the layouts that allow for absolute positioning set the right styles or
> selector on the parent.
>
> My 2 cents,
> -Alex
>
> On 6/5/18, 11:44 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> FYI, I applied this change to my PrintUI app and it seems like we had
> applied quite a few ugly work-arounds to get things to be positioned
> correctly. We did not realize at the time that it was due to the default
> being position: static. Switching the default to position: relative
> simplifies element positioning a lot, and enables us to get rid of a lot of
> positional overrides to make things stay where they should.
>
> If there’s no objections, I’ll apply this change. It might require some
> changes to client apps, but this is mostly to remove work-arounds that
> shouldn’t have been required in the first place and I think it’s worth-while.
>
> The change will also enable us to get rid of forced reflow when setting x
> and y values to UIBase which is a major performance sore-spot.
>
> Harbs
>
>> On Jun 5, 2018, at 8:00 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>>
>> Ah, ok. How would a user disable that selector in case it did something
>> undesirable?
>>
>> -Alex
>>
>> On 6/4/18, 1:56 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> Sorry I was a bit confused. The selector that works is:
>>
>> .Application * {
>> position: relative;
>> }
>>
>>> On Jun 4, 2018, at 11:32 PM, Harbs <harbs.li...@gmail.com> 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 <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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
