Interesting idea, but I thought there was concern about the global selector affecting HTML around the app?
I'm still puzzled that offsetParent doesn't matter. My understanding is that the left/top styles are relative to the nearest parentNode with position!=static, so the position styles of intermediate parents matter. I think that's why you have to set position!=static throughout the DOM to remove the offsetParent code. Another way to think about the right solution is to understand what the recommended practices are for using left/top styles in existing HTML/JS/CSS websites? How often do people use left/top? And when they do, do they set position!=static on all parents or do they remember what the nearest positioned parentNode is and do the math? Thoughts? -Alex On 6/8/18, 5:17 AM, "Harbs" <[email protected]> wrote: I just added an implementation of this. I added a “DefaultRelativePosition” bead to the “simplify-position” feature branch. The bead sets the default positioning using a global selector. The bead is extremely light-weight. I think it’s a good solution. Below is an app which has the default set globally to relative and behaves as you’d expect in Flex. Both the logical and visible position of child is 30,30, and the left and top values retain a value of 20 instead of 30. It might make sense to make the defaults in Express and Emulation to use this bead. FWIW, The size of parent is the size of the child plus the padding and not the size of the child including the top and left values. (i.e. it’s 55.55x38 instead of 75.55x58) This is due to how relative works in HTML where the drawn object is “ghosted” out of the natural position. I’m pretty sure that the size was different in Flex. <?xml version="1.0" encoding="utf-8"?> <js:Application xmlns:fx="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C06fc012e86d54bf5a35008d5cd39bd6c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636640570230701246&sdata=Ex21LJwxhWVEjXcbMWxqzGpDodTWReABiJO%2Fjz95ECY%3D&reserved=0"; xmlns:js="library://ns.apache.org/royale/basic" xmlns:ns1="*" applicationComplete="onComplete()" > <fx:Script> <![CDATA[ import org.apache.royale.utils.PointUtils; import org.apache.royale.geom.Point; private function onComplete():void{ var point:Point = PointUtils.localToGlobal(new Point(0,0),child); trace(point); } ]]> </fx:Script> <js:valuesImpl> <js:SimpleCSSValuesImpl /> </js:valuesImpl> <js:beads> <js:DefaultRelativePosition/> </js:beads> <js:initialView> <js:View> <js:Group id="theparent" style="padding:10px" > <js:Group id="child" x="20" y="20" > <js:Label text="Hello"/> </js:Group> </js:Group> </js:View> </js:initialView> </js:Application> (Traces org.apache.royale.geom.Point {x: 30, y: 30}) Harbs > On Jun 8, 2018, at 10:40 AM, Harbs <[email protected]> wrote: > >> >> I'm still wondering if BasicLayout and/or the x,y setters should set parentNode.style.positon!=static. Then I think we could drop the offsetParent check. > > We can drop the offsetParent check either way, but maybe non-static should be set. I really would not want that code to be in the x and y setters though unless it could be made *really* cheap. I suppose we could have a “position” property on UIBase which could be used to determine whether non-static needs to be set. The position setter could be overridden in component sets to allow for inline styles vs css selectors. > > The most PAYG way to handle this is probably with a bead which adds the global position: relative selector. That approach should work fine as long as the app is the body. If we ever add support to inserting a Royale app into a div on a page, the global selector might cause unexpected effects on the rest of the page which might rely on the default position: static setting.
