I could certainly not be understanding how pervasive this problem is. I don't
remember the x and y properties always being in ProductsView. In fact, it is
not in the original FlexStore demo. I wonder if was added later?
I would hope that I could just bring up an HTML editor and use display:flex to
layout 4 widgets horizontally and get one to stretch to fill the remaining
space without setting position or the left and top styles. I think that would
be the minimal implementation. Then offsetParent should be needed either. We
should remove the x and y from this demo and make sure we understand how to get
this to work and generate that minimal DOM+CSS. IMO, a framework should not
implement wide-ranging defaults because someone hacked something in.
Then, if we need to compensate for migrating users having hacked x and y values
then we can create PAYG beads/layouts for that.
Can you provide more details where you needed to set x,y in your app? We have
to remember to get out of the Flex mindset that there is only one Application
or Layout. It might turn out to be more efficient in some cases to have an
AbsolutePositioningApplication if folks did find that they had to use x,y a lot
in Flex. But I think Carlos has achieved good results in his demos without
setting x,y and just using display:flex. He reported that there is no impact
by adding that universal selector, but that also implies that it was
just-in-case for him.
My 2 cents,
-Alex
On 6/6/18, 11:25 AM, "Harbs" <harbs.li...@gmail.com> wrote:
I don’t think you realize the full extent of the effect. It’s not just “in
case” someone wants x and y values. It’s also to *prevent the need* to specify
x and y values which shouldn’t need to be specified.
Let’s take a piece of ProductsView in RoyaleStore:
<js:Container
className="colorPanel"
height="100%" width="100%"
>
<js:beads>
<js:OneFlexibleChildHorizontalLayout flexibleChild="spacer" />
</js:beads>
<productsView:Grip id="filterGrip"
gripIcon="assets/icon_magnifier.png"
gripTip="Show filter panel" click="currentState =
'showFilter'"/>
<productsView:ProductFilterPanel x="{filterGrip.width}" y="0"
id="filterPanel" width="265" height="100%"
filter="catalogPanel.filter(event.filter, event.live)"
compare="catalogPanel.compare(filterPanel.productList.getProducts())"
initComplete="if (catalog) filterPanel.filter.count =
catalog.length"/>
<js:Spacer id="spacer" />
<productsView:ProductCart id="cartPanel" width="265" height="100%"
/>
<productsView:Grip id="cartGrip"
gripIcon="assets/icon_cart_empty.png"
gripTip="Show cart" click="currentState = 'showCart'" />
</js:Container>
It’s using a flex layout. The flex layout should position the child
elements. Unfortunately it doesn’t which is why we have the following code
there:
x="{filterGrip.width}”
Without that, the filterGrip space is not accounted for. This is because
the default is static rather than relative. Changing the default to relative
removes the necessity to specify an x position dependent on the sibling size.
I was forced to add similar code in my app.
We are also forced to add code to calculate offsetParent which is not PAYG
both in terms of code and performance.
Simply put: static is a bad default. Default relative positioning gives
more expected results in 99% of use cases and usually results in *less* code.
My $0.02,
Harbs
> On Jun 6, 2018, at 7:37 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Setting position:relative "just-in-case" someone needs to use x,y is not
PAYG, IMO.
