Yeah. If you’d need static for some reason, you’d specify that. I think needing static instead of relative would be pretty rare. Here’s an interesting article.[1]
I think the fact that static is the default in HTML is more of conceptual decision (less opinion on positioning) than a practical one (static leads to unexpected layout). Even describing what static does is complicated as opposed to relative which is conceptually simple.[2] All in all, relative seems like the right default for Royale apps to have. My $0.02, Harbs [1]https://css-tricks.com/what-if-there-was-no-position-static/ <https://css-tricks.com/what-if-there-was-no-position-static/> [2]https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document <https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document> > On Jun 5, 2018, at 8:23 AM, Alex Harui <[email protected]> wrote: > > What I'm wondering is how you would make it so it was as if that selector > wasn't specified at all. I guess the default value for position is "static" > so the user would specify position: static? > > -Alex > > On 6/4/18, 10:03 PM, "Harbs" <[email protected]> wrote: > > Any other selector should disable that one because that’s about as > unspecific as you can get and the higher level of specificity always wins. > >> On Jun 5, 2018, at 8:00 AM, Alex Harui <[email protected]> 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" <[email protected]> wrote: >> >> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > > >
