In the case of the controlsPallette, how did it get its size? I could certainly understand that if you didn't have position!=static, that setting top on the dockAndOuterContainer would have no effect, but you shouldn't have had to set y or top in the first place. IIRC, you couldn't use x,y in Flex layouts like VerticalLayout/HorizontalLayout so migrating code shouldn't be using it. It is fine to create other layouts that support x,y as exceptions.
In general, for a framework, we want to make sure we understand and fix the fundamental problem before we address any hacks/exceptions. IMO, the fundamental problem in the scenarios you've provided so far is that the layout did not do what was expected so someone tried using x,y to fix it. First we need that layout do what is expected, then worry about how folks might resolve other issues, if any. In ProductsView in RoyaleStore, the grip is an image loaded later, so there might have been an issue there, especially on the SWF side, but I would expect the browser to automatically re-layout once the grip image loaded. I dug through Git history and found that I was the one who hacked in the x,y. It could be that early on, the layout did not use FlexBox so we had a similar problem of responding to the grip image loading late. But we should remove the x,y and see if there is still a problem and ponder the right fix for that. ProductsView should not need to be setting x,y. So, IMO, it would be nice to do a similar investigation of controlsPallette. IMO, if you examine that div, it's offsetHeight should be 40 and if it is then you shouldn't need to set style.top=40 on docAndOuterContainer which means that it shouldn't matter what style.position is. My 2 cents, -Alex On 6/6/18, 2:12 PM, "Harbs" <[email protected]> wrote: > On Jun 6, 2018, at 11:05 PM, Harbs <[email protected]> wrote: > > <js:Label x="20" y="20" > text="{locStr.UPLOAD_YOUR_IMAGE}"/> > It actually, looks like the x and y values no longer have an effect on this particular component, but there was clearly a reason they were needed to be specified at some point… Another one. I have an image which needs to stick to the bottom right of the app. To do that I needed to following: top: calc(100% - 21px); left: calc(100% - 187px); position: fixed; With a default of position: relative, I’m able to do this: top: -21px; float: right; right: 10px; This being said, it actually looks like I’m wrong about the way to set the defaults being .Application *{}. This actually has a *higher* specificity than .foo{}.[1] I think the only way to guarantee that it’ll have a lower specificity than other selectors is to use: *{ position: relative; } I’m less happy about this option than ."Application *” because it’ll effect elements outside the Royale app if it’s not in an iframe. Harbs [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F&data=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765&sdata=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F&data=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765&sdata=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D&reserved=0>
