I created a “simplify-position” feature branch which does away with the 
offsetParent logic in UIBase. It does not change anything regarding position: 
static.

I have tested with my own app and a number of the examples. I haven’t found any 
problems yet.

Input welcome…

Harbs

> On Jun 7, 2018, at 12:20 PM, Harbs <[email protected]> wrote:
> 
>> So, IMO, it would be nice to do a similar investigation of controlsPallette.
> 
> You are right. Removing the y value has no effect.
> 
> I am wondering that maybe it makes sense to apply relative to the Container 
> CSS selector and possibly a few others.
> 
> I’m trying to understand the specific cases where:
>                 if (positioner.parentNode != positioner.offsetParent)
> 
> Is required in setX, get x and setY, get y in UIBase. I would *really* like 
> to get rid of that code, and I’m, wondering what doing so would cause.
> 
>> On Jun 7, 2018, at 12:36 AM, Alex Harui <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 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] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>>> On Jun 6, 2018, at 11:05 PM, Harbs <[email protected] 
>>> <mailto:[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>
>>  
>> <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>>
> 

Reply via email to