IMO, we first need to address the fundamental problem. Who needs to set x,y
and why? Otherwise you are trying to solve a problem "just-in-case".
Effects like MoveEffect will set x,y. For sure, absolute positioning layouts
will but then the layout can set properties on the parent. PopUps probably
need to set x,y.
But otherwise, who needs to set x,y and why?
-Alex
On 6/7/18, 11:27 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> So, if we don't force position!=static throughout the DOM, then you have
to have code that compensates for that difference.
I don’t think I agree. Right now we’re modifying the x and y values because
we *might* care about the offsetParent. That’s not PAYG. In fact, the set
values will be *wrong* if the position of the parent is changed after the x and
y values of the child are set.
Based on my observations, most apps will not need to set the values based
on the offsetParent, so hard-wiring that code in is not PAYG. This is
especially true since setting x and y currently forces a reflow of HTML. We’re
suffering a major performance hit for no reason.
In cases where we care about the parentOffset, we can use observedX and
observedY utility methods which account for offsetParent. That seems much more
PAYG to me.
Removing the assumptions of reliance on offsetParent seems to eliminate all
needs to care about parent positioning.
My $0.02,
Harbs
> On Jun 7, 2018, at 8:23 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> IIRC, the parentNode is always the parent of the child if you examine the
DOM. offsetParent is the parent or grandparent, etc, that has position !=
static, and left/top/right/bottom styles are always relative to offsetParent.
So, if we don't force position!=static throughout the DOM, then you have to
have code that compensates for that difference.
>
> IMO, the key issue is whether it is "ok" to force position!=static
throughout the DOM. Can someone look at other JS frameworks? I'll bet most of
them use border-box like we do. If the major JS frameworks have opted for
position!=static, then it might be the right thing for us to do as well. IMO,
we would like to make it easy for snippets found on the internet to work in
Royale and they may not all presume position!-static.
>
> Also, IMO, our Containers should not presume position!=static.
Containers accept assignable Layouts and the Layouts can set position!=static
on the children and be appropriately named (VerticalLayoutWithXYSupport).
That's PAYG to me. Remember that TLCs should have very little assumptions as
illustrated in the ExplodedComponent example. The beads can make assumptions
and be appropriately named and documented.
>
> My 2 cents,
> -Alex
>
> On 6/7/18, 6:15 AM, "Harbs" <harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com>> wrote:
>
> 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 <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID
<mailto:aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID
<mailto:aha...@adobe.com.INVALID>>> 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" <harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com>>> wrote:
>>>
>>>
>>>> On Jun 6, 2018, at 11:05 PM, Harbs <harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com>>> 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>>
<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>>>
