I'm all for this kind of changes. Things should be as easy and straight
forward as possible, so if we can simplify something to get the same, this
is better. And we are still on 0.9.x so is not something we *can* do, is
something we *must* do if it enhances the overall solution and is possible.
I think the proposed branch is the best way to go to know exactly what is
needed. But in theory sounds good to me.
thanks
2018-06-06 18:05 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> > ... 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%7Cb3fbf0fe3aef48f404ce08d5ca2f
> 0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636637225574936981&sdata=tQL6czkhz6TGNfiVuLzM8BpNPd%
> 2BudGur3FGTGyZUJew%3D&reserved=0
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
