Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

AIUI, the issue is how it is possible, if at all, to use position:absolute or 
position:relative selectively in the DOM.  IIRC, it isn't a matter of creating 
a descendant selector for the object you want to position, it is setting the 
position style on all of its parents without affecting any other of the other 
children of those parents in the DOM that might not be expecting position to be 
set.  Because position not only changes the position, but it seems to affect 
what offsetWidth is of those parents.

I haven't looked at existing JS frameworks and successful JS websites.  Maybe 
position is an "all-or-nothing" kind of choice.  You have to decide to use it 
and deal with setting position!=static throughout the DOM, or use it in many 
places and pick a few offsetParents to base all of your math on, or not use it 
all and rely on margins and padding and other tricks.   Note that Flex does not 
support margins and Royale can, so maybe proper use of margin can eliminate 
some of the reliance on x,y in Royale.

So it may be that we need different groups of beads to allow these three 
choices.  If you choose position!=static you use a particular bead and it uses 
different handlers for x,y,width/height.  And maybe we should make a 
"RelativeToMeBead" that you stick on a UI widget and all children x,y is 
relative to that.

So maybe, Royale should provide choices.  What is really hard and not PAYG is 
trying to make one method handle all of these situations.

Just thinking out loud,
-Alex

On 6/11/18, 12:36 AM, "Harbs"  wrote:

We could always have a bead which sets:

.foo *{
   position: static;
}
To reset the defaults of all elements below “foo” to static.

Of course to change it to something else, you’d need:
.foo .baz{
   position: absolute;
}

I’m not sure how well this would work with the Jewel layout beads. I’m not 
sure what the specificity is on that.

Harbs

> On Jun 11, 2018, at 10:11 AM, Alex Harui  wrote:
> 
> The emulation Application is based on Container and thus creates a Div.  
It may not stay that way, but we did it so that the SystemManager can parent 
the app like it does in Flex.
> 
> Feel free to commit the bead.  It won't hurt anything and some folks will 
be able to use it.  I'm still wondering what the right answer is going to be 
for the emulation component sets.  Or what to do if someone does have some part 
of the DOM that they do not want style.position set.  There is no CSS way to 
specify "set style on all parents", AFAIK, which is would help reduce 
side-effects.
> 
> Later,
> -Alex
> 
> On 6/8/18, 9:02 AM, "Harbs"  wrote:
> 
>> Interesting idea, but I thought there was concern about the global 
selector affecting HTML around the app?
> 
>Currently, we don’t have an Application class that attaches to regular 
divs It always controls the body element. Since we control the whole page, it’s 
not a problem. If we do get to the point where a Royale app can be injected 
into a random div, then setting a global selector might be a problem if there’s 
other HTML which relies on static. We can have heavier-duty beads to deal with 
setting relative positioning in those cases.
> 
>Harbs
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Not disagreeing with anything you write here…

FWIW, I was thinking of adding a “constrainment” bead which would allow 
left/right/top/bottom values. This would likely work in the context of other 
layouts and be applied to components directly.

> On Jun 11, 2018, at 6:43 PM, Alex Harui  wrote:
> 
> So yeah, % works differently in Royale compared to Flex for some layouts, but 
> may not for other layouts.  It is ok if Harbs app couldn't use some of our 
> Basic layouts without adding calc().  If other sites can go to production 
> without using calc() then our simplest layouts should allow them to do so.  
> If there is a pattern where many apps use calc() a certain way, that should 
> be encapsulated into another layout in Royale.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

IMO, regarding layouts, there will be many kinds of layouts.  In Royale we want 
to give people choices.

-The emulation component sets will mimic Flex layout behavior where % is 
calculated on available space.  I'm pretty sure these will use absolute 
positioning and never set element.style.width to a percentage.  In these 
layouts, replicating Flex behavior is more important than performance.
-Most of the Basic layouts (and hopefully lots of other layouts) are simply 
intended to produce common patterns in the DOM.  No promise of backward 
compatibility with Flex.  Instead of thinking about Flex layouts when writing 
these Basic layouts, the goal should be to work from the browser backwards.  
IOW, if you looked at how 100 different existing websites handle some aspect of 
layout, find the common/popular pattern, and create a Royale layout bead that 
sets styles on the parent and/or children in that pattern.  That's why 
VerticalLayout just sets display:block on every child, or some other layout 
sets display:flex.  The goal is to be able to have Royale efficiently produce 
the same DOM that other sites are using successfully today.
-Other layouts may address common problems.  If you go to StackOverflow you can 
find lots of people running into the same HTML layout problem over and over 
again.  If we can encapsulate the solution on SO, we will save lots of people 
lots of time.  We won't worry too much about performance and code size of these 
solutions.  I think we sort of have a few like that already for handling nested 
divs with percentage sizes in display:flex layouts.
-Custom layouts.  We might someday make a 3DividedPanes layout that handles the 
layout of 3 panes like many email clients or our ASDoc if that helps save 
people time and hassle.  And there will be custom layouts for DataGrid and 
other complex components.

So yeah, % works differently in Royale compared to Flex for some layouts, but 
may not for other layouts.  It is ok if Harbs app couldn't use some of our 
Basic layouts without adding calc().  If other sites can go to production 
without using calc() then our simplest layouts should allow them to do so.  If 
there is a pattern where many apps use calc() a certain way, that should be 
encapsulated into another layout in Royale.

My 2 cents,
-Alex

On 6/11/18, 4:27 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

I think Yishay is on track. I'm still changing my mind on how things are on
html, different to flex.
For example, in flexbox there's no gap number, but the layout knows it
should be gap between elements (with "space-between").
So Flexbox put the space, how many? that depends on parent sizes...to make
the simulation without space-between we use margins...
At the end, are different approaches, and sometimes is very difficult to
handle as we did in Flex, maybe not impossible. What I'm trying
to do now is see get more experience and see how to get the best solution
of both worlds...

2018-06-11 12:25 GMT+02:00 Harbs :

> The problem is that the child does not have a way of knowing what the
> extra space surrounding the parent (such as padding) will be.
>
> One day, I’m probably going to work on a constrained layout…
>
> > On Jun 11, 2018, at 1:20 PM, Yishay Weiss 
> wrote:
> >
> > I guess we’re a bit prejudiced coming from Flex. Once you let go of the
> notion that percentages are not of the available space but of the total
> parent space, it sort of makes sense.
>
>


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C78b99b908a0c471ac54d08d5cf8e48b6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636643132375937723=xj27KElCDdfT%2BH5%2FSB%2FwCaF7JIcvJ%2FNyDHslDtqLhak%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

I think Yishay is on track. I'm still changing my mind on how things are on
html, different to flex.
For example, in flexbox there's no gap number, but the layout knows it
should be gap between elements (with "space-between").
So Flexbox put the space, how many? that depends on parent sizes...to make
the simulation without space-between we use margins...
At the end, are different approaches, and sometimes is very difficult to
handle as we did in Flex, maybe not impossible. What I'm trying
to do now is see get more experience and see how to get the best solution
of both worlds...

2018-06-11 12:25 GMT+02:00 Harbs :

> The problem is that the child does not have a way of knowing what the
> extra space surrounding the parent (such as padding) will be.
>
> One day, I’m probably going to work on a constrained layout…
>
> > On Jun 11, 2018, at 1:20 PM, Yishay Weiss 
> wrote:
> >
> > I guess we’re a bit prejudiced coming from Flex. Once you let go of the
> notion that percentages are not of the available space but of the total
> parent space, it sort of makes sense.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

The problem is that the child does not have a way of knowing what the extra 
space surrounding the parent (such as padding) will be.

One day, I’m probably going to work on a constrained layout…

> On Jun 11, 2018, at 1:20 PM, Yishay Weiss  wrote:
> 
> I guess we’re a bit prejudiced coming from Flex. Once you let go of the 
> notion that percentages are not of the available space but of the total 
> parent space, it sort of makes sense.

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

I guess we’re a bit prejudiced coming from Flex. Once you let go of the notion 
that percentages are not of the available space but of the total parent space, 
it sort of makes sense.




From: Harbs 
Sent: Monday, June 11, 2018 11:29:38 AM
To: dev@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

FWIW, I’ve found that the single-most painful part of developing using Royale 
has been layouts.

I *think* defaulting to relative might help some issues, but things like 
percentages simply don’t work as you’d expect in HTML. I have been forced to 
stick calc() css in at least 12 places in my app.

> On Jun 11, 2018, at 11:00 AM, Carlos Rovira  wrote:
>
> Hi,
>
> I'm finding some problems with all this in Jewel as I go deeper with
> layouts. I'll write about it soon, I hope to solve some issue and left most
> important to discuss.
> As I get something working, I see a collateral effect that makes other
> thing that was working fail on some way...it's like a puzzle where
> positioning, layout, states must adjust to work ok. And still I'm getting
> hard time with ClassSelectorList. I think we have an huge issue with class
> name handling through Royale, since is not consistent, and class names are
> essential in html. For example since layouts class names are some kind of
> "typenames", those are removed when a user adds some class...
>
> This is a sneak peak of what I'm finding, and hope to work more over it and
> try to raise only essential issues
>
>
>
> 2018-06-11 9:36 GMT+02:00 Harbs :
>
>> We could always have a bead which sets:
>>
>> .foo *{
>>   position: static;
>> }
>> To reset the defaults of all elements below “foo” to static.
>>
>> Of course to change it to something else, you’d need:
>> .foo .baz{
>>   position: absolute;
>> }
>>
>> I’m not sure how well this would work with the Jewel layout beads. I’m not
>> sure what the specificity is on that.
>>
>> Harbs
>>
>>> On Jun 11, 2018, at 10:11 AM, Alex Harui 
>> wrote:
>>>
>>> The emulation Application is based on Container and thus creates a Div.
>> It may not stay that way, but we did it so that the SystemManager can
>> parent the app like it does in Flex.
>>>
>>> Feel free to commit the bead.  It won't hurt anything and some folks
>> will be able to use it.  I'm still wondering what the right answer is going
>> to be for the emulation component sets.  Or what to do if someone does have
>> some part of the DOM that they do not want style.position set.  There is no
>> CSS way to specify "set style on all parents", AFAIK, which is would help
>> reduce side-effects.
>>>
>>> Later,
>>> -Alex
>>>
>>> On 6/8/18, 9:02 AM, "Harbs"  wrote:
>>>
>>>> Interesting idea, but I thought there was concern about the global
>> selector affecting HTML around the app?
>>>
>>>   Currently, we don’t have an Application class that attaches to
>> regular divs It always controls the body element. Since we control the
>> whole page, it’s not a problem. If we do get to the point where a Royale
>> app can be injected into a random div, then setting a global selector might
>> be a problem if there’s other HTML which relies on static. We can have
>> heavier-duty beads to deal with setting relative positioning in those cases.
>>>
>>>   Harbs
>>>
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

I think is important that we reach the most simple and cross browser way to
get things work. At least Royale should be able to make all most used
layouts
only declaring containers and layouts in its simplest forms. Then people
that want to make some not conventional things could need to make some
calculations, bindings and settings. Back in flex days, I remember to watch
code with calculations and bindings, I always think that 95% of times that
was not needed and only makes your code complex, less performant and
difficult to debug.
This is an important target for us
Let's see if we can get something cool here


2018-06-11 10:29 GMT+02:00 Harbs :

> FWIW, I’ve found that the single-most painful part of developing using
> Royale has been layouts.
>
> I *think* defaulting to relative might help some issues, but things like
> percentages simply don’t work as you’d expect in HTML. I have been forced
> to stick calc() css in at least 12 places in my app.
>
> > On Jun 11, 2018, at 11:00 AM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > I'm finding some problems with all this in Jewel as I go deeper with
> > layouts. I'll write about it soon, I hope to solve some issue and left
> most
> > important to discuss.
> > As I get something working, I see a collateral effect that makes other
> > thing that was working fail on some way...it's like a puzzle where
> > positioning, layout, states must adjust to work ok. And still I'm getting
> > hard time with ClassSelectorList. I think we have an huge issue with
> class
> > name handling through Royale, since is not consistent, and class names
> are
> > essential in html. For example since layouts class names are some kind of
> > "typenames", those are removed when a user adds some class...
> >
> > This is a sneak peak of what I'm finding, and hope to work more over it
> and
> > try to raise only essential issues
> >
> >
> >
> > 2018-06-11 9:36 GMT+02:00 Harbs :
> >
> >> We could always have a bead which sets:
> >>
> >> .foo *{
> >>   position: static;
> >> }
> >> To reset the defaults of all elements below “foo” to static.
> >>
> >> Of course to change it to something else, you’d need:
> >> .foo .baz{
> >>   position: absolute;
> >> }
> >>
> >> I’m not sure how well this would work with the Jewel layout beads. I’m
> not
> >> sure what the specificity is on that.
> >>
> >> Harbs
> >>
> >>> On Jun 11, 2018, at 10:11 AM, Alex Harui 
> >> wrote:
> >>>
> >>> The emulation Application is based on Container and thus creates a Div.
> >> It may not stay that way, but we did it so that the SystemManager can
> >> parent the app like it does in Flex.
> >>>
> >>> Feel free to commit the bead.  It won't hurt anything and some folks
> >> will be able to use it.  I'm still wondering what the right answer is
> going
> >> to be for the emulation component sets.  Or what to do if someone does
> have
> >> some part of the DOM that they do not want style.position set.  There
> is no
> >> CSS way to specify "set style on all parents", AFAIK, which is would
> help
> >> reduce side-effects.
> >>>
> >>> Later,
> >>> -Alex
> >>>
> >>> On 6/8/18, 9:02 AM, "Harbs"  wrote:
> >>>
>  Interesting idea, but I thought there was concern about the global
> >> selector affecting HTML around the app?
> >>>
> >>>   Currently, we don’t have an Application class that attaches to
> >> regular divs It always controls the body element. Since we control the
> >> whole page, it’s not a problem. If we do get to the point where a Royale
> >> app can be injected into a random div, then setting a global selector
> might
> >> be a problem if there’s other HTML which relies on static. We can have
> >> heavier-duty beads to deal with setting relative positioning in those
> cases.
> >>>
> >>>   Harbs
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

FWIW, I’ve found that the single-most painful part of developing using Royale 
has been layouts.

I *think* defaulting to relative might help some issues, but things like 
percentages simply don’t work as you’d expect in HTML. I have been forced to 
stick calc() css in at least 12 places in my app.

> On Jun 11, 2018, at 11:00 AM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I'm finding some problems with all this in Jewel as I go deeper with
> layouts. I'll write about it soon, I hope to solve some issue and left most
> important to discuss.
> As I get something working, I see a collateral effect that makes other
> thing that was working fail on some way...it's like a puzzle where
> positioning, layout, states must adjust to work ok. And still I'm getting
> hard time with ClassSelectorList. I think we have an huge issue with class
> name handling through Royale, since is not consistent, and class names are
> essential in html. For example since layouts class names are some kind of
> "typenames", those are removed when a user adds some class...
> 
> This is a sneak peak of what I'm finding, and hope to work more over it and
> try to raise only essential issues
> 
> 
> 
> 2018-06-11 9:36 GMT+02:00 Harbs :
> 
>> We could always have a bead which sets:
>> 
>> .foo *{
>>   position: static;
>> }
>> To reset the defaults of all elements below “foo” to static.
>> 
>> Of course to change it to something else, you’d need:
>> .foo .baz{
>>   position: absolute;
>> }
>> 
>> I’m not sure how well this would work with the Jewel layout beads. I’m not
>> sure what the specificity is on that.
>> 
>> Harbs
>> 
>>> On Jun 11, 2018, at 10:11 AM, Alex Harui 
>> wrote:
>>> 
>>> The emulation Application is based on Container and thus creates a Div.
>> It may not stay that way, but we did it so that the SystemManager can
>> parent the app like it does in Flex.
>>> 
>>> Feel free to commit the bead.  It won't hurt anything and some folks
>> will be able to use it.  I'm still wondering what the right answer is going
>> to be for the emulation component sets.  Or what to do if someone does have
>> some part of the DOM that they do not want style.position set.  There is no
>> CSS way to specify "set style on all parents", AFAIK, which is would help
>> reduce side-effects.
>>> 
>>> Later,
>>> -Alex
>>> 
>>> On 6/8/18, 9:02 AM, "Harbs"  wrote:
>>> 
 Interesting idea, but I thought there was concern about the global
>> selector affecting HTML around the app?
>>> 
>>>   Currently, we don’t have an Application class that attaches to
>> regular divs It always controls the body element. Since we control the
>> whole page, it’s not a problem. If we do get to the point where a Royale
>> app can be injected into a random div, then setting a global selector might
>> be a problem if there’s other HTML which relies on static. We can have
>> heavier-duty beads to deal with setting relative positioning in those cases.
>>> 
>>>   Harbs
>>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi,

I'm finding some problems with all this in Jewel as I go deeper with
layouts. I'll write about it soon, I hope to solve some issue and left most
important to discuss.
As I get something working, I see a collateral effect that makes other
thing that was working fail on some way...it's like a puzzle where
positioning, layout, states must adjust to work ok. And still I'm getting
hard time with ClassSelectorList. I think we have an huge issue with class
name handling through Royale, since is not consistent, and class names are
essential in html. For example since layouts class names are some kind of
"typenames", those are removed when a user adds some class...

This is a sneak peak of what I'm finding, and hope to work more over it and
try to raise only essential issues



2018-06-11 9:36 GMT+02:00 Harbs :

> We could always have a bead which sets:
>
> .foo *{
>position: static;
> }
> To reset the defaults of all elements below “foo” to static.
>
> Of course to change it to something else, you’d need:
> .foo .baz{
>position: absolute;
> }
>
> I’m not sure how well this would work with the Jewel layout beads. I’m not
> sure what the specificity is on that.
>
> Harbs
>
> > On Jun 11, 2018, at 10:11 AM, Alex Harui 
> wrote:
> >
> > The emulation Application is based on Container and thus creates a Div.
> It may not stay that way, but we did it so that the SystemManager can
> parent the app like it does in Flex.
> >
> > Feel free to commit the bead.  It won't hurt anything and some folks
> will be able to use it.  I'm still wondering what the right answer is going
> to be for the emulation component sets.  Or what to do if someone does have
> some part of the DOM that they do not want style.position set.  There is no
> CSS way to specify "set style on all parents", AFAIK, which is would help
> reduce side-effects.
> >
> > Later,
> > -Alex
> >
> > On 6/8/18, 9:02 AM, "Harbs"  wrote:
> >
> >> Interesting idea, but I thought there was concern about the global
> selector affecting HTML around the app?
> >
> >Currently, we don’t have an Application class that attaches to
> regular divs It always controls the body element. Since we control the
> whole page, it’s not a problem. If we do get to the point where a Royale
> app can be injected into a random div, then setting a global selector might
> be a problem if there’s other HTML which relies on static. We can have
> heavier-duty beads to deal with setting relative positioning in those cases.
> >
> >Harbs
> >
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

We could always have a bead which sets:

.foo *{
   position: static;
}
To reset the defaults of all elements below “foo” to static.

Of course to change it to something else, you’d need:
.foo .baz{
   position: absolute;
}

I’m not sure how well this would work with the Jewel layout beads. I’m not sure 
what the specificity is on that.

Harbs

> On Jun 11, 2018, at 10:11 AM, Alex Harui  wrote:
> 
> The emulation Application is based on Container and thus creates a Div.  It 
> may not stay that way, but we did it so that the SystemManager can parent the 
> app like it does in Flex.
> 
> Feel free to commit the bead.  It won't hurt anything and some folks will be 
> able to use it.  I'm still wondering what the right answer is going to be for 
> the emulation component sets.  Or what to do if someone does have some part 
> of the DOM that they do not want style.position set.  There is no CSS way to 
> specify "set style on all parents", AFAIK, which is would help reduce 
> side-effects.
> 
> Later,
> -Alex
> 
> On 6/8/18, 9:02 AM, "Harbs"  wrote:
> 
>> Interesting idea, but I thought there was concern about the global selector 
>> affecting HTML around the app?
> 
>Currently, we don’t have an Application class that attaches to regular 
> divs It always controls the body element. Since we control the whole page, 
> it’s not a problem. If we do get to the point where a Royale app can be 
> injected into a random div, then setting a global selector might be a problem 
> if there’s other HTML which relies on static. We can have heavier-duty beads 
> to deal with setting relative positioning in those cases.
> 
>Harbs
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

The emulation Application is based on Container and thus creates a Div.  It may 
not stay that way, but we did it so that the SystemManager can parent the app 
like it does in Flex.

Feel free to commit the bead.  It won't hurt anything and some folks will be 
able to use it.  I'm still wondering what the right answer is going to be for 
the emulation component sets.  Or what to do if someone does have some part of 
the DOM that they do not want style.position set.  There is no CSS way to 
specify "set style on all parents", AFAIK, which is would help reduce 
side-effects.

Later,
-Alex

On 6/8/18, 9:02 AM, "Harbs"  wrote:

> Interesting idea, but I thought there was concern about the global 
selector affecting HTML around the app?

Currently, we don’t have an Application class that attaches to regular divs 
It always controls the body element. Since we control the whole page, it’s not 
a problem. If we do get to the point where a Royale app can be injected into a 
random div, then setting a global selector might be a problem if there’s other 
HTML which relies on static. We can have heavier-duty beads to deal with 
setting relative positioning in those cases.

Harbs

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Right, except for maybe SkinParts?.  I'm guessing the compiler does not check 
against the base class for existing properties.  I don't remember if it was 
legal to have the base class have other properties that are slots to be filled 
in by the MXML or not.   Someone will have to run some tests in Flex and find 
out.  There were these notions of "code-behind" back in Flex where all AS was 
in the base class for the MXML.

-Alex

On 6/8/18, 8:54 AM, "Harbs"  wrote:

How does the compiler figure out illegal values?

Any property of the main class should not be a valid id. Right?

> On Jun 8, 2018, at 6:42 PM, Alex Harui  wrote:
> 
> The compiler should probably report an error.  You shouldn't be able to 
do id="width" or even id="id".
> 
> My 2 cents,
> -Alex
> 
> On 6/8/18, 1:27 AM, "Harbs"  wrote:
> 
>Would defining a “parent" property on Application with a default value 
of null fix this?
> 
>> On Jun 8, 2018, at 10:56 AM, Harbs  wrote:
>> 
>> BTW,
>> 
>> This code causes an endless loop in MouseEvent.mouseOverHandler. The 
Group is the “parent” of the application, so “parent” is never null…
>> 
>>> On Jun 8, 2018, at 2:25 AM, Harbs mailto:harbs.li...@gmail.com>> wrote:
>>> 
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> Interesting idea, but I thought there was concern about the global selector 
> affecting HTML around the app?

Currently, we don’t have an Application class that attaches to regular divs It 
always controls the body element. Since we control the whole page, it’s not a 
problem. If we do get to the point where a Royale app can be injected into a 
random div, then setting a global selector might be a problem if there’s other 
HTML which relies on static. We can have heavier-duty beads to deal with 
setting relative positioning in those cases.

Harbs

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

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"  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.


https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009=02%7C01%7Caharui%40adobe.com%7C06fc012e86d54bf5a35008d5cd39bd6c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636640570230701246=Ex21LJwxhWVEjXcbMWxqzGpDodTWReABiJO%2Fjz95ECY%3D=0;
xmlns:js="library://ns.apache.org/royale/basic" 
xmlns:ns1="*" applicationComplete="onComplete()" >




















(Traces org.apache.royale.geom.Point {x: 30, y: 30})

Harbs

> On Jun 8, 2018, at 10:40 AM, Harbs  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.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

How does the compiler figure out illegal values?

Any property of the main class should not be a valid id. Right?

> On Jun 8, 2018, at 6:42 PM, Alex Harui  wrote:
> 
> The compiler should probably report an error.  You shouldn't be able to do 
> id="width" or even id="id".
> 
> My 2 cents,
> -Alex
> 
> On 6/8/18, 1:27 AM, "Harbs"  wrote:
> 
>Would defining a “parent" property on Application with a default value of 
> null fix this?
> 
>> On Jun 8, 2018, at 10:56 AM, Harbs  wrote:
>> 
>> BTW,
>> 
>> This code causes an endless loop in MouseEvent.mouseOverHandler. The Group 
>> is the “parent” of the application, so “parent” is never null…
>> 
>>> On Jun 8, 2018, at 2:25 AM, Harbs >> > wrote:
>>> 
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

The compiler should probably report an error.  You shouldn't be able to do 
id="width" or even id="id".

My 2 cents,
-Alex

On 6/8/18, 1:27 AM, "Harbs"  wrote:

Would defining a “parent" property on Application with a default value of 
null fix this?

> On Jun 8, 2018, at 10:56 AM, Harbs  wrote:
> 
> BTW,
> 
> This code causes an endless loop in MouseEvent.mouseOverHandler. The 
Group is the “parent” of the application, so “parent” is never null…
> 
>> On Jun 8, 2018, at 2:25 AM, Harbs mailto:harbs.li...@gmail.com>> wrote:
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Piotr Zarzycki]

I love solution with Bead!

On Fri, Jun 8, 2018, 2:17 PM Harbs  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.
>
> 
> http://ns.adobe.com/mxml/2009;
> xmlns:js="library://ns.apache.org/royale/basic"
> xmlns:ns1="*" applicationComplete="onComplete()" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> (Traces org.apache.royale.geom.Point {x: 30, y: 30})
>
> Harbs
>
> > On Jun 8, 2018, at 10:40 AM, Harbs  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.
>
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

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.


http://ns.adobe.com/mxml/2009;
xmlns:js="library://ns.apache.org/royale/basic" xmlns:ns1="*" 
applicationComplete="onComplete()" >




















(Traces org.apache.royale.geom.Point {x: 30, y: 30})

Harbs

> On Jun 8, 2018, at 10:40 AM, Harbs  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.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Would defining a “parent" property on Application with a default value of null 
fix this?

> On Jun 8, 2018, at 10:56 AM, Harbs  wrote:
> 
> BTW,
> 
> This code causes an endless loop in MouseEvent.mouseOverHandler. The Group is 
> the “parent” of the application, so “parent” is never null…
> 
>> On Jun 8, 2018, at 2:25 AM, Harbs > > wrote:
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

BTW,

This code causes an endless loop in MouseEvent.mouseOverHandler. The Group is 
the “parent” of the application, so “parent” is never null…

> On Jun 8, 2018, at 2:25 AM, Harbs  wrote:
> 
>
>
>
>
>
>
>
>
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> On Jun 8, 2018, at 2:47 AM, Alex Harui  wrote:
> 
> Well, you changed the test a bit.  I guess I should have had child show a 
> border.  Where would the border be?  And isn't child.offsetParent != 
> child.parentNode?
> 
> Also shouldn't the test be:  
> var point:Point = PointUtils.localToGlobal(new Point(0, 0),child);

That would be 10 with or without the parentOffset code.

> Also, I don't remember if Group defaults to BasicLayout or not and what code 
> BasicLayout ran.
> 
> But aren't you saying that the label shows up in an unexpected place?   I 
> think we know where the label would show up in Flex (30,30).  What code will 
> make both the label and border show up correctly in Royale, or should we give 
> up on that working like Flex?  I think this may be why early FlexJS did set 
> position!=static throughout the DOM.

Yes. That was probably why. Does it show in an unexpected place? Maybe. It 
depends on what you call unexpected.

Maybe a Group should have a default layout of “Relative” or something. I think 
it’s fair to say that an emulation component set should set the default to 
relative.

> I would hope we could find a way to get these scenarios to work like Flex.  I 
> think to get it to work, we need parent.style.position=relative instead of 
> child.style.position=relative?

No. It’s child. Left and top values have no effect on elements which are static.

>  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.

> 
> Thoughts?
> -Alex
> 
> On 6/7/18, 4:25 PM, "Harbs"  wrote:
> 
>I was waiting to test it.
> 
>Here’s the results:
> 
>
> 
> xmlns:fx="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009=02%7C01%7Caharui%40adobe.com%7Cf2a842aed6694578539708d5cccdfc59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636640107452777321=j0vYBh5Vanfu5s6VWv4MK9iaG%2FuUgqAgTYzP44HpfAU%3D=0;
>xmlns:js="library://ns.apache.org/royale/basic" 
> xmlns:ns1="*" applicationComplete="onComplete()" >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>Traces:
> 
>org.apache.royale.geom.Point {x: 30, y: 30}
> 
>I think that’s the result you wanted.
> 
>As to why: because it adds 20 to the bounding box of the element which is 
> 10,10.
> 
>Mind you: The *visual* placement of the word Hello is actually 10,10 
> rather than 30,30, but the *logical* placement of it is 30,30. The reason is 
> because the x and y values have no effect. To make the visual placement match 
> the logical placement, the position of “child” needs to be changed to 
> relative.
> 
>Harbs
> 
>> On Jun 8, 2018, at 1:50 AM, Alex Harui  wrote:
>> 
>> Harbs,
>> 
>> I posted a 3 MXML tag example.  Will it work like it does in Flex with your 
>> changes?  If so, how/why?
>> 
>> If not, then we need the old code.  It is unfortunate that it causes extra 
>> reflows, but setting x,y should be rare.  And if you can propose a different 
>> solution that is PAYG, even better.  I keep wondering if we should go back 
>> to setting position!=static on the parentNode when x,y is set.
>> 
>> The scenario where offsetParent changes also needs to be understood to know 
>> how rare it is or if it is a result of some other bug.  We have to be 
>> careful about spending lots of time on these cases if they are corner cases 
>> or a side-effect.
>> 
>> All I'm trying to do is make sure your analysis and proposed changes are 
>> correct.  There have been scenarios cited (RoyaleStore) and solutions 
>> proposed (Application * selector0 that weren't valid so I'm just trying to 
>> help make sure this is right.  It just isn't making sense to me that 
>> offsetParent doesn't matter in the x,y calculation or that there is 
>> framework code that changes offsetParent.  I don't want to worry about the 
>> performance of x,y being set if most UI really shouldn't be setting it.  

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Well, you changed the test a bit.  I guess I should have had child show a 
border.  Where would the border be?  And isn't child.offsetParent != 
child.parentNode?

Also shouldn't the test be:  
 var point:Point = PointUtils.localToGlobal(new Point(0, 0),child);

Also, I don't remember if Group defaults to BasicLayout or not and what code 
BasicLayout ran.

But aren't you saying that the label shows up in an unexpected place?   I think 
we know where the label would show up in Flex (30,30).  What code will make 
both the label and border show up correctly in Royale, or should we give up on 
that working like Flex?  I think this may be why early FlexJS did set 
position!=static throughout the DOM.

I would hope we could find a way to get these scenarios to work like Flex.  I 
think to get it to work, we need parent.style.position=relative instead of 
child.style.position=relative?  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.

Thoughts?
-Alex

On 6/7/18, 4:25 PM, "Harbs"  wrote:

I was waiting to test it.

Here’s the results:



https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009=02%7C01%7Caharui%40adobe.com%7Cf2a842aed6694578539708d5cccdfc59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636640107452777321=j0vYBh5Vanfu5s6VWv4MK9iaG%2FuUgqAgTYzP44HpfAU%3D=0;
xmlns:js="library://ns.apache.org/royale/basic" 
xmlns:ns1="*" applicationComplete="onComplete()" >

















Traces:

org.apache.royale.geom.Point {x: 30, y: 30}

I think that’s the result you wanted.

As to why: because it adds 20 to the bounding box of the element which is 
10,10.

Mind you: The *visual* placement of the word Hello is actually 10,10 rather 
than 30,30, but the *logical* placement of it is 30,30. The reason is because 
the x and y values have no effect. To make the visual placement match the 
logical placement, the position of “child” needs to be changed to relative.

Harbs

> On Jun 8, 2018, at 1:50 AM, Alex Harui  wrote:
> 
> Harbs,
> 
> I posted a 3 MXML tag example.  Will it work like it does in Flex with 
your changes?  If so, how/why?
> 
> If not, then we need the old code.  It is unfortunate that it causes 
extra reflows, but setting x,y should be rare.  And if you can propose a 
different solution that is PAYG, even better.  I keep wondering if we should go 
back to setting position!=static on the parentNode when x,y is set.
> 
> The scenario where offsetParent changes also needs to be understood to 
know how rare it is or if it is a result of some other bug.  We have to be 
careful about spending lots of time on these cases if they are corner cases or 
a side-effect.
> 
> All I'm trying to do is make sure your analysis and proposed changes are 
correct.  There have been scenarios cited (RoyaleStore) and solutions proposed 
(Application * selector0 that weren't valid so I'm just trying to help make 
sure this is right.  It just isn't making sense to me that offsetParent doesn't 
matter in the x,y calculation or that there is framework code that changes 
offsetParent.  I don't want to worry about the performance of x,y being set if 
most UI really shouldn't be setting it.  But for sure, it has to produce the 
right values.
> 
> Thanks,
> -Alex
> 
> On 6/7/18, 3:26 PM, "Harbs"  wrote:
> 
> 
>> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
>> 
>>   In your animation code example, having the offsetParent code in the 
setter makes the animation *way* less efficient. There is a an extra forced 
reflow for every assignment of the new value.
>> 
>> I don't understand this point.  Can you provide more detail?  I would 
imagine animations are going to cause reflows.   If there is a way to do 
animations without resulting in a reflow that would be great.
> 
>The point is that there is a forced reflow. There will definitely be a 
reflow when the browser draws the animation change, but the offsetParent code 
forces the browser to calculate an extra reflow during the code execution prior 
to setting the x value.
> 
>This has two problems:
>1. There is two reflows per cycle instead of one. If the animation 
sets both x and y values, there will be three reflows (the first two forced) 
instead of one.
>2. The first reflow is forced to happen during javascript execution 
rather than when the browser decides it’s the optimum time to do so.
> 
>> 
>>> I think you are saying there is a bug in the current code, but it 
somehow involves 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I was waiting to test it.

Here’s the results:



http://ns.adobe.com/mxml/2009;
xmlns:js="library://ns.apache.org/royale/basic" xmlns:ns1="*" 
applicationComplete="onComplete()" >

















Traces:

org.apache.royale.geom.Point {x: 30, y: 30}

I think that’s the result you wanted.

As to why: because it adds 20 to the bounding box of the element which is 10,10.

Mind you: The *visual* placement of the word Hello is actually 10,10 rather 
than 30,30, but the *logical* placement of it is 30,30. The reason is because 
the x and y values have no effect. To make the visual placement match the 
logical placement, the position of “child” needs to be changed to relative.

Harbs

> On Jun 8, 2018, at 1:50 AM, Alex Harui  wrote:
> 
> Harbs,
> 
> I posted a 3 MXML tag example.  Will it work like it does in Flex with your 
> changes?  If so, how/why?
> 
> If not, then we need the old code.  It is unfortunate that it causes extra 
> reflows, but setting x,y should be rare.  And if you can propose a different 
> solution that is PAYG, even better.  I keep wondering if we should go back to 
> setting position!=static on the parentNode when x,y is set.
> 
> The scenario where offsetParent changes also needs to be understood to know 
> how rare it is or if it is a result of some other bug.  We have to be careful 
> about spending lots of time on these cases if they are corner cases or a 
> side-effect.
> 
> All I'm trying to do is make sure your analysis and proposed changes are 
> correct.  There have been scenarios cited (RoyaleStore) and solutions 
> proposed (Application * selector0 that weren't valid so I'm just trying to 
> help make sure this is right.  It just isn't making sense to me that 
> offsetParent doesn't matter in the x,y calculation or that there is framework 
> code that changes offsetParent.  I don't want to worry about the performance 
> of x,y being set if most UI really shouldn't be setting it.  But for sure, it 
> has to produce the right values.
> 
> Thanks,
> -Alex
> 
> On 6/7/18, 3:26 PM, "Harbs"  wrote:
> 
> 
>> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
>> 
>>   In your animation code example, having the offsetParent code in the setter 
>> makes the animation *way* less efficient. There is a an extra forced reflow 
>> for every assignment of the new value.
>> 
>> I don't understand this point.  Can you provide more detail?  I would 
>> imagine animations are going to cause reflows.   If there is a way to do 
>> animations without resulting in a reflow that would be great.
> 
>The point is that there is a forced reflow. There will definitely be a 
> reflow when the browser draws the animation change, but the offsetParent code 
> forces the browser to calculate an extra reflow during the code execution 
> prior to setting the x value.
> 
>This has two problems:
>1. There is two reflows per cycle instead of one. If the animation sets 
> both x and y values, there will be three reflows (the first two forced) 
> instead of one.
>2. The first reflow is forced to happen during javascript execution rather 
> than when the browser decides it’s the optimum time to do so.
> 
>> 
>>> I think you are saying there is a bug in the current code, but it somehow 
>>> involves offsetParent changing.  Can you explain what causes offsetParent 
>>> to change?
>> 
>>   If/when the parent (or grandparent or great-grandparent, etc.) element 
>> position changes from static to some other value, the offsetParent will 
>> change.
>> 
>> Again, how important/prevalent is such a scenario?
> 
>It’s hard to say, but one such scenario sparked this discussion. I think 
> that avoiding lifecycle issues is pretty important.
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Harbs,

I posted a 3 MXML tag example.  Will it work like it does in Flex with your 
changes?  If so, how/why?

If not, then we need the old code.  It is unfortunate that it causes extra 
reflows, but setting x,y should be rare.  And if you can propose a different 
solution that is PAYG, even better.  I keep wondering if we should go back to 
setting position!=static on the parentNode when x,y is set.

The scenario where offsetParent changes also needs to be understood to know how 
rare it is or if it is a result of some other bug.  We have to be careful about 
spending lots of time on these cases if they are corner cases or a side-effect.

All I'm trying to do is make sure your analysis and proposed changes are 
correct.  There have been scenarios cited (RoyaleStore) and solutions proposed 
(Application * selector0 that weren't valid so I'm just trying to help make 
sure this is right.  It just isn't making sense to me that offsetParent doesn't 
matter in the x,y calculation or that there is framework code that changes 
offsetParent.  I don't want to worry about the performance of x,y being set if 
most UI really shouldn't be setting it.  But for sure, it has to produce the 
right values.

Thanks,
-Alex

On 6/7/18, 3:26 PM, "Harbs"  wrote:


> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
> 
>In your animation code example, having the offsetParent code in the 
setter makes the animation *way* less efficient. There is a an extra forced 
reflow for every assignment of the new value.
> 
> I don't understand this point.  Can you provide more detail?  I would 
imagine animations are going to cause reflows.   If there is a way to do 
animations without resulting in a reflow that would be great.

The point is that there is a forced reflow. There will definitely be a 
reflow when the browser draws the animation change, but the offsetParent code 
forces the browser to calculate an extra reflow during the code execution prior 
to setting the x value.

This has two problems:
1. There is two reflows per cycle instead of one. If the animation sets 
both x and y values, there will be three reflows (the first two forced) instead 
of one.
2. The first reflow is forced to happen during javascript execution rather 
than when the browser decides it’s the optimum time to do so.

> 
>> I think you are saying there is a bug in the current code, but it 
somehow involves offsetParent changing.  Can you explain what causes 
offsetParent to change?
> 
>If/when the parent (or grandparent or great-grandparent, etc.) element 
position changes from static to some other value, the offsetParent will change.
> 
> Again, how important/prevalent is such a scenario?

It’s hard to say, but one such scenario sparked this discussion. I think 
that avoiding lifecycle issues is pretty important.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
> 
>In your animation code example, having the offsetParent code in the setter 
> makes the animation *way* less efficient. There is a an extra forced reflow 
> for every assignment of the new value.
> 
> I don't understand this point.  Can you provide more detail?  I would imagine 
> animations are going to cause reflows.   If there is a way to do animations 
> without resulting in a reflow that would be great.

The point is that there is a forced reflow. There will definitely be a reflow 
when the browser draws the animation change, but the offsetParent code forces 
the browser to calculate an extra reflow during the code execution prior to 
setting the x value.

This has two problems:
1. There is two reflows per cycle instead of one. If the animation sets both x 
and y values, there will be three reflows (the first two forced) instead of one.
2. The first reflow is forced to happen during javascript execution rather than 
when the browser decides it’s the optimum time to do so.

> 
>> I think you are saying there is a bug in the current code, but it somehow 
>> involves offsetParent changing.  Can you explain what causes offsetParent to 
>> change?
> 
>If/when the parent (or grandparent or great-grandparent, etc.) element 
> position changes from static to some other value, the offsetParent will 
> change.
> 
> Again, how important/prevalent is such a scenario?

It’s hard to say, but one such scenario sparked this discussion. I think that 
avoiding lifecycle issues is pretty important.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

I'm not arguing to keep this code and much as make sure it is right.  I did 
ponder removing x,y from Royale.  But I think x,y should exist for backward 
compatibility.  And if it is going to exist, then it should work like it did in 
Flex.  Which means setting x,y to the offset you expect from the component's 
parent (is that what you mean by "observed").  But if the actual offsetParent 
is something else, then code needs to factor that in.  I don't think we want 
folks to have to consider how the browser and offsetParent work internally.

Maybe I'm not fully understanding the problem.  Let's say that you have:


  

  


I think this produces a DOM like this:


  

   
  


AIUI, with the changes you propose, the child Group will be 20 pixels in from 
the body, not 30.  But in Flex it would be at 30.  That's because the 
offsetParent for child is body.  Some legacy testing code might verify that 
localToGlobal(child.x) == 30.  Will it with your proposed changes?

More inline...

On 6/7/18, 2:32 PM, "Harbs"  wrote:

The only case it will not work is if three conditions are fulfilled:

1. The x value started off being undefined and you do someWidget.x += 10;
2.  The offsetParent is not the parent.
3. The element is offset from the offsetParent at some value other than 0.

#1 is invalid.  X cannot be undefined.  That would be a bug if it is.  It 
should return 0 if it has never been touched.
#2 I would think that offsetParent != parentNode in most of the DOM elements in 
RoyaleStore or any example.  If not, why not?
#3 I thought padding would offset the element so most elements in our examples 
have an offsetLeft/Top != 0


I have yet to find a case where this is a problem. If there is, then by all 
means, I’d like to know, but I’m willing to bet there’s some way of fixing it 
other than paying for that code in UIBase.

For sure, I'm not a big fan of the old code either, I'm just having trouble 
believing it isn't needed.

> It is not PAYG to worry about the performance of an API that is rarely 
used.  That is how PAYG works.  You pay for it when you use it.  If you can 
lower the cost without making everyone pay for it, great, but the most 
important principle is that you cannot make everyone pay for it just-in-case.  
Migrating apps may pay more in order to change less code, but AIUI, the trend 
in UI design in general is to get away from absolute positioning and use 
flexbox and CSSGrid in order to have responsive UIs, so I don't see x,y 
performance as important.

I did a lot of profiling. Trust me. It’s important. It’s the single-largest 
performance bottleneck I’ve found in Royale apps. Sometimes, you can improve it 
by being smarter about where you set x and y values, but not always. It effects 
every use of x=“” and y=“” used in MXML. The vast majority of apps will have 
some x and y value somewhere.

Of course if you profile lots of changes to x,y it will be a big performance 
bottleneck.  My point is that with the trend for responsive UI, there should be 
much fewer, if any, changes to x,y so it shouldn't matter how slow that code 
is.   I think we disagree as to how often x,y will be set.  I would still like 
to know why folks need to set it in so many places in their UI.

In your animation code example, having the offsetParent code in the setter 
makes the animation *way* less efficient. There is a an extra forced reflow for 
every assignment of the new value.

I don't understand this point.  Can you provide more detail?  I would imagine 
animations are going to cause reflows.   If there is a way to do animations 
without resulting in a reflow that would be great.

> I think you are saying there is a bug in the current code, but it somehow 
involves offsetParent changing.  Can you explain what causes offsetParent to 
change?

If/when the parent (or grandparent or great-grandparent, etc.) element 
position changes from static to some other value, the offsetParent will change.

Again, how important/prevalent is such a scenario?

Thanks,
-Alex 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> On Jun 7, 2018, at 10:44 PM, Alex Harui  wrote:
> 
> Are you testing with the selector that sets position!=static throughout the 
> DOM?

No. I’m testing with no extra selectors. I dropped that idea. Thanks for 
pointing out the problems with it. :-) I don’t think it’s usually necessary. 
The real problem turns out to be the use of offsetParent.

> If not, then I think that the "get what you set" rule has to apply and I 
> would think that code is necessary.  That was also a rule in Flex.  The 
> following was always true:
> 
> Var value:int = 10;
> someWidget.x = value;
> value == someWidget.x; // this was always true.

This is still true. With the current code in the branch, once set, the getter 
and setter will always match.

> Otherwise, I think simple animation code might fail:
> 
> Function timerHandler():void
> {
>  someWidget.x += 10;
> }
> 
> The above reads  x and sets it to x+10.

This will work (and I see animations working perfectly in RoyaleStore). The 
only case it will not work is if three conditions are fulfilled:

1. The x value started off being undefined and you do someWidget.x += 10;
2.  The offsetParent is not the parent.
3. The element is offset from the offsetParent at some value other than 0.

I have yet to find a case where this is a problem. If there is, then by all 
means, I’d like to know, but I’m willing to bet there’s some way of fixing it 
other than paying for that code in UIBase.

> It is not PAYG to worry about the performance of an API that is rarely used.  
> That is how PAYG works.  You pay for it when you use it.  If you can lower 
> the cost without making everyone pay for it, great, but the most important 
> principle is that you cannot make everyone pay for it just-in-case.  
> Migrating apps may pay more in order to change less code, but AIUI, the trend 
> in UI design in general is to get away from absolute positioning and use 
> flexbox and CSSGrid in order to have responsive UIs, so I don't see x,y 
> performance as important.

I did a lot of profiling. Trust me. It’s important. It’s the single-largest 
performance bottleneck I’ve found in Royale apps. Sometimes, you can improve it 
by being smarter about where you set x and y values, but not always. It effects 
every use of x=“” and y=“” used in MXML. The vast majority of apps will have 
some x and y value somewhere.

In your animation code example, having the offsetParent code in the setter 
makes the animation *way* less efficient. There is a an extra forced reflow for 
every assignment of the new value.

Also, it’s extra code in UIBase “just in case” we care about the offsetParent 
relative position. I don’t see how you can claim it’s not a violation of PAYG. 
It’s code in UIBase that is just in case. Also, the vast majority of uses of x 
and y do not need that code. It’s “just in case”. It also has nasty side 
effects. Without a clear need for this code, I don’t know why you are arguing 
so strongly to keep it.

> I think you are saying there is a bug in the current code, but it somehow 
> involves offsetParent changing.  Can you explain what causes offsetParent to 
> change?

If/when the parent (or grandparent or great-grandparent, etc.) element position 
changes from static to some other value, the offsetParent will change.

> 
> Thanks,
> -Alex
> 
> On 6/7/18, 12:22 PM, "Harbs"  > wrote:
> 
>> I hope the current implementation tries to mimic Flash/Flex for backward 
>> compatibility reasons. 
> 
>Here’s the kicker:
> 
>I have not yet found a *SINGLE* case yet where this attempt to mimic the 
> Flash/Flex behavior is necessary to *GET THE SAME RESULT*. Both my own app 
> and the examples that I’ve tested seem to work perfectly without the 
> offsetParent code. The *ONLY* effect I’ve seen from this code is that it:
> 
>1. Causes bugs in the layout lifecycle.
>2. Causes a significant performance hit when writing x and y values.
> 
>So, to me the question is *WHAT IS THE CASE WHERE THIS CODE IS ACTUALLY 
> NEEDED*? Sure. I understand theoretically why it’s needed, but I don’t see an 
> *ACTUAL* problem with removing the code. It seems to me like the theoretical 
> case can be handled with utility functions.
> 
>I’ll try to do some more testing, but after my initial tests, I’m 
> questioning whether this code is serving a function anymore. I remember it 
> being needed at some point in the past, but it could be it’s legacy code 
> which is no longer useful.
> 
>Harbs
> 
>> On Jun 7, 2018, at 10:13 PM, Alex Harui  wrote:
>> 
>> I'm not sure I'm understanding.
>> 
>> There is no x,y in HTML/JS, so we can make it mean anything we want it to.  
>> I hope the current implementation tries to mimic Flash/Flex for backward 
>> compatibility reasons.  We could agree to change that if we really want to, 
>> but I think backward-compatibility is useful here.
>> 
>> In Flex/Flash, if you set the x,y to 10,10, then the object is offset by 10 
>> pixels from 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Are you testing with the selector that sets position!=static throughout the DOM?

If not, then I think that the "get what you set" rule has to apply and I would 
think that code is necessary.  That was also a rule in Flex.  The following was 
always true:

Var value:int = 10;
someWidget.x = value;
value == someWidget.x; // this was always true.

Otherwise, I think simple animation code might fail:

Function timerHandler():void
{
  someWidget.x += 10;
}

The above reads  x and sets it to x+10.

It is not PAYG to worry about the performance of an API that is rarely used.  
That is how PAYG works.  You pay for it when you use it.  If you can lower the 
cost without making everyone pay for it, great, but the most important 
principle is that you cannot make everyone pay for it just-in-case.  Migrating 
apps may pay more in order to change less code, but AIUI, the trend in UI 
design in general is to get away from absolute positioning and use flexbox and 
CSSGrid in order to have responsive UIs, so I don't see x,y performance as 
important.

I think you are saying there is a bug in the current code, but it somehow 
involves offsetParent changing.  Can you explain what causes offsetParent to 
change?

Thanks,
-Alex

On 6/7/18, 12:22 PM, "Harbs"  wrote:

>  I hope the current implementation tries to mimic Flash/Flex for backward 
compatibility reasons. 

Here’s the kicker:

I have not yet found a *SINGLE* case yet where this attempt to mimic the 
Flash/Flex behavior is necessary to *GET THE SAME RESULT*. Both my own app and 
the examples that I’ve tested seem to work perfectly without the offsetParent 
code. The *ONLY* effect I’ve seen from this code is that it:

1. Causes bugs in the layout lifecycle.
2. Causes a significant performance hit when writing x and y values.

So, to me the question is *WHAT IS THE CASE WHERE THIS CODE IS ACTUALLY 
NEEDED*? Sure. I understand theoretically why it’s needed, but I don’t see an 
*ACTUAL* problem with removing the code. It seems to me like the theoretical 
case can be handled with utility functions.

I’ll try to do some more testing, but after my initial tests, I’m 
questioning whether this code is serving a function anymore. I remember it 
being needed at some point in the past, but it could be it’s legacy code which 
is no longer useful.

Harbs

> On Jun 7, 2018, at 10:13 PM, Alex Harui  wrote:
> 
> I'm not sure I'm understanding.
> 
> There is no x,y in HTML/JS, so we can make it mean anything we want it 
to.  I hope the current implementation tries to mimic Flash/Flex for backward 
compatibility reasons.  We could agree to change that if we really want to, but 
I think backward-compatibility is useful here.
> 
> In Flex/Flash, if you set the x,y to 10,10, then the object is offset by 
10 pixels from the top-left of the parent.  If you read back x,y it will be 
10,10.  However, in Royale, we map x,y to the "left" and "top" styles.  if the 
parentNode has position=static, then we need code to compensate for that.
> 
> One way is to make sure nobody has position=static.  That doesn't seem 
PAYG, might break snippets from the internet, and can be overridden by someone 
setting position=static on an element (not sure why anyone would do that).
> 
> Another way is, when you set x,y, we set position!=static on the parent.  
I think we tried that and there was some problem, but maybe we should try that 
again.  That would be PAYG, IMO.  It is only applied when used.
> 
> But again, I want to understand the fundamental use cases.  The one you 
cited in RoyaleStore turned out to be an un-needed hack.  What are the real use 
cases we need to consider?  How important/prevalent is setting x,y outside of 
effects, popups, and absolute layout going to be?   Otherwise, the code can be 
inefficient because you only pay for it in rare cases, which is more PAYG then 
making every node pay for it "just-in-case".
> 
> My 2 cents,
> -Alex
> 
> On 6/7/18, 12:00 PM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>I don’t think I was clear enough. The original issue that started this 
thread is actually caused by the code which sets the y value based on the 
parentOffset. If the parentOffset is ignored, the issue goes away and we don’t 
have to care about layout lifecycles.
> 
>For the few cases where we need to read and set the *actual observed* 
x and y positions based on the offsetParent which might be different than the 
actual parent, we can use utility functions to get and set these values.
> 
>> On Jun 7, 2018, at 9:27 PM, Harbs  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. 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

>  I hope the current implementation tries to mimic Flash/Flex for backward 
> compatibility reasons. 

Here’s the kicker:

I have not yet found a *SINGLE* case yet where this attempt to mimic the 
Flash/Flex behavior is necessary to *GET THE SAME RESULT*. Both my own app and 
the examples that I’ve tested seem to work perfectly without the offsetParent 
code. The *ONLY* effect I’ve seen from this code is that it:

1. Causes bugs in the layout lifecycle.
2. Causes a significant performance hit when writing x and y values.

So, to me the question is *WHAT IS THE CASE WHERE THIS CODE IS ACTUALLY 
NEEDED*? Sure. I understand theoretically why it’s needed, but I don’t see an 
*ACTUAL* problem with removing the code. It seems to me like the theoretical 
case can be handled with utility functions.

I’ll try to do some more testing, but after my initial tests, I’m questioning 
whether this code is serving a function anymore. I remember it being needed at 
some point in the past, but it could be it’s legacy code which is no longer 
useful.

Harbs

> On Jun 7, 2018, at 10:13 PM, Alex Harui  wrote:
> 
> I'm not sure I'm understanding.
> 
> There is no x,y in HTML/JS, so we can make it mean anything we want it to.  I 
> hope the current implementation tries to mimic Flash/Flex for backward 
> compatibility reasons.  We could agree to change that if we really want to, 
> but I think backward-compatibility is useful here.
> 
> In Flex/Flash, if you set the x,y to 10,10, then the object is offset by 10 
> pixels from the top-left of the parent.  If you read back x,y it will be 
> 10,10.  However, in Royale, we map x,y to the "left" and "top" styles.  if 
> the parentNode has position=static, then we need code to compensate for that.
> 
> One way is to make sure nobody has position=static.  That doesn't seem PAYG, 
> might break snippets from the internet, and can be overridden by someone 
> setting position=static on an element (not sure why anyone would do that).
> 
> Another way is, when you set x,y, we set position!=static on the parent.  I 
> think we tried that and there was some problem, but maybe we should try that 
> again.  That would be PAYG, IMO.  It is only applied when used.
> 
> But again, I want to understand the fundamental use cases.  The one you cited 
> in RoyaleStore turned out to be an un-needed hack.  What are the real use 
> cases we need to consider?  How important/prevalent is setting x,y outside of 
> effects, popups, and absolute layout going to be?   Otherwise, the code can 
> be inefficient because you only pay for it in rare cases, which is more PAYG 
> then making every node pay for it "just-in-case".
> 
> My 2 cents,
> -Alex
> 
> On 6/7/18, 12:00 PM, "Harbs"  > wrote:
> 
>I don’t think I was clear enough. The original issue that started this 
> thread is actually caused by the code which sets the y value based on the 
> parentOffset. If the parentOffset is ignored, the issue goes away and we 
> don’t have to care about layout lifecycles.
> 
>For the few cases where we need to read and set the *actual observed* x 
> and y positions based on the offsetParent which might be different than the 
> actual parent, we can use utility functions to get and set these values.
> 
>> On Jun 7, 2018, at 9:27 PM, Harbs  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 >>  >> >> 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 
>>> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> I don’t think I was clear enough

That still was not clear enough. The problem was that the value being applied 
to the style is *different* than the value specified. So, the code was writing 
a y value of (something like) 15, but what’s actually written is the (observed) 
offset of 500 plus 15 for a total of 515. When the offsetParent then changes, 
the value which should have been 15 is not 515 and the element is in the 
totally wrong place.

We’re simply trying to be too smart for our own good.

The real question is: what is x and y? I think it should be the *specified* 
positions and not strictly than the *observed* positions. Sure, we should 
measure the values relative to the immediate parent if no values are previously 
specified, but we shouldn’t care about the observed position relative to the 
offsetParent unless code specifically asks for it. If the offsetParent is not 
the parent, then the x and y positions should be measured as 0.

My $0.0,
Harbs


> On Jun 7, 2018, at 10:00 PM, Harbs  wrote:
> 
> I don’t think I was clear enough. The original issue that started this thread 
> is actually caused by the code which sets the y value based on the 
> parentOffset. If the parentOffset is ignored, the issue goes away and we 
> don’t have to care about layout lifecycles.
> 
> For the few cases where we need to read and set the *actual observed* x and y 
> positions based on the offsetParent which might be different than the actual 
> parent, we can use utility functions to get and set these values.
> 
>> On Jun 7, 2018, at 9:27 PM, Harbs > > 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 >> > 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" >> > 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 >>> > 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 != 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

I'm not sure I'm understanding.

There is no x,y in HTML/JS, so we can make it mean anything we want it to.  I 
hope the current implementation tries to mimic Flash/Flex for backward 
compatibility reasons.  We could agree to change that if we really want to, but 
I think backward-compatibility is useful here.

In Flex/Flash, if you set the x,y to 10,10, then the object is offset by 10 
pixels from the top-left of the parent.  If you read back x,y it will be 10,10. 
 However, in Royale, we map x,y to the "left" and "top" styles.  if the 
parentNode has position=static, then we need code to compensate for that.

One way is to make sure nobody has position=static.  That doesn't seem PAYG, 
might break snippets from the internet, and can be overridden by someone 
setting position=static on an element (not sure why anyone would do that).

Another way is, when you set x,y, we set position!=static on the parent.  I 
think we tried that and there was some problem, but maybe we should try that 
again.  That would be PAYG, IMO.  It is only applied when used.

But again, I want to understand the fundamental use cases.  The one you cited 
in RoyaleStore turned out to be an un-needed hack.  What are the real use cases 
we need to consider?  How important/prevalent is setting x,y outside of 
effects, popups, and absolute layout going to be?   Otherwise, the code can be 
inefficient because you only pay for it in rare cases, which is more PAYG then 
making every node pay for it "just-in-case".

My 2 cents,
-Alex

On 6/7/18, 12:00 PM, "Harbs"  wrote:

I don’t think I was clear enough. The original issue that started this 
thread is actually caused by the code which sets the y value based on the 
parentOffset. If the parentOffset is ignored, the issue goes away and we don’t 
have to care about layout lifecycles.

For the few cases where we need to read and set the *actual observed* x and 
y positions based on the offsetParent which might be different than the actual 
parent, we can use utility functions to get and set these values.

> On Jun 7, 2018, at 9:27 PM, Harbs  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 mailto: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" 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
>> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> Who needs to set x,y and why?

Anyone who wants to read or set a position of an element. That’s usually going 
to be inside a container which has a Basic or Relative layout. Generally, the 
element shouldn’t need to care whether that’s relative to the parent or 
grandparent.

A common case is setting the position of a component inside an ItemRenderer, a 
Label, etc.

I think the better question is why we should care whether this is relative to 
the parent or grandparent. Once the value is set, the read value will always be 
right.

Harbs

> On Jun 7, 2018, at 9:59 PM, Alex Harui  wrote:
> 
> 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"  > 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  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" >  > >> 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 >> > 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 >>>  > 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I don’t think I was clear enough. The original issue that started this thread 
is actually caused by the code which sets the y value based on the 
parentOffset. If the parentOffset is ignored, the issue goes away and we don’t 
have to care about layout lifecycles.

For the few cases where we need to read and set the *actual observed* x and y 
positions based on the offsetParent which might be different than the actual 
parent, we can use utility functions to get and set these values.

> On Jun 7, 2018, at 9:27 PM, Harbs  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 > > 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" > > 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 >> > 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 >>>  >> 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 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

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"  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  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" 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  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 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 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> 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  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"  > 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  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 >>  >> >> 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 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

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"  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  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 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" mailto:harbs.li...@gmail.com>> wrote:
>> 
>> 
>>> On Jun 6, 2018, at 11:05 PM, Harbs mailto:harbs.li...@gmail.com>> wrote:
>>> 
>>> >>   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:
>> 
>>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

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  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 > > 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" > > wrote:
>> 
>> 
>>> On Jun 6, 2018, at 11:05 PM, Harbs >> > wrote:
>>> 
>>> >>   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=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0
>>  
>> 
>>  
>> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> 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  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"  > wrote:
> 
> 
>> On Jun 6, 2018, at 11:05 PM, Harbs  wrote:
>> 
>>  >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=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0
>  
> 
>  
>   
> 

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

For what it’s worth, I removed x="{filterGrip.width}" and it  works the same. 
So it’s probably just legacy code.
From: Harbs<mailto:harbs.li...@gmail.com>
Sent: Wednesday, June 6, 2018 9:25 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

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:

















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  wrote:
>
> Setting position:relative "just-in-case" someone needs to use x,y is not 
> PAYG, IMO.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

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"  wrote:


> On Jun 6, 2018, at 11:05 PM, Harbs  wrote:
> 
>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=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0
 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Here’s one example very similar to the RoyaleStore problem:







Which produces:





The dockAndOuterContainer needed the y=“40” or it occupies the same space as 
the controlPalette. With a default of position: relative this is no longer 
needed.

I don’t know the full details, but flexbox does not allow for the space of the 
first item unless position is relative.

Here’s another one:







UPLOAD YOUR IMAGE

In this case, I needed to set the style directly (I don’t remember why, but I 
had a *very* hard time getting it to go where it belonged). The component had 
nothing which prevented the correct positioning itself, but it’s nested inside 
another component which uses a flexbox layout. I think that had something to do 
with the positioning problem. These issues are really hard to diagnose.

Again, a default of position: relative is the solution to this problem, and 
with that default, hard-coding the top and left values is no longer necessary.

My takeaway is simply that a default of relative gives more predictable results 
and layouts do not need to care what other layouts they are nested inside. 
That’s really important for predictable results in a framework.

> On Jun 6, 2018, at 9:43 PM, Alex Harui  wrote:
> 
> Can you provide more details where you needed to set x,y in your app?

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

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"  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:

















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  wrote:
> 
> Setting position:relative "just-in-case" someone needs to use x,y is not 
PAYG, IMO.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

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:

















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  wrote:
> 
> Setting position:relative "just-in-case" someone needs to use x,y is not 
> PAYG, IMO.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Harbs is proposing that, like border-box, we apply position:relative to all 
elements in the DOM.  My understanding is that you can do that via:

.Application * {
position: relative;
   }

If it has zero impact on Jewel's use of flexbox then I think it is safe to use. 
 I just want to make sure folks won't be wanting to turn that off at some point.

Another area of concern is in encapsulating existing DOM patterns.  When folks 
want to make existing JS frameworks work in Royale, they may want to copy code 
from those JS frameworks and wrap them in Royale classes.  But if the code they 
borrow did not assume that all elements had position:relative, the copied code 
may not work correctly.  That's why the application of PAYG principles, IMO, is 
to only apply it to the parent containers that need it, even though that runs a 
bit more code to do that.  Setting position:relative "just-in-case" someone 
needs to use x,y is not PAYG, IMO.

My 2 cents,
-Alex

On 6/6/18, 9:06 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex

2018-06-06 17:23 GMT+02:00 Alex Harui :

> This sounds scary to me because it affects the entire DOM, and not very
> PAYG.  Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
>

What you refer exactly to try? let me know to do it .


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C29273bf16fa1457dc71a08d5cbc777a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638979924029830=77fNpWL%2FJwcjHJCRD4a%2BZARrUeHPTLSnLABXoGcS1I8%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

I'm all for this kind of changes. Things should be as easy and straight
forward as possible, so if we can simplify something to get the same, this
is better. And we are still on 0.9.x so is not something we *can* do, is
something we *must* do if it enhances the overall solution and is possible.
I think the proposed branch is the best way to go to know exactly what is
needed. But in theory sounds good to me.

thanks


2018-06-06 18:05 GMT+02:00 Harbs :

> > ... and not very PAYG.
>
> On the contrary.
>
> The same way we are applying box-sizing: border-box because it is a better
> default and prevents extra processing, applying relative instead of static
> as a default allows us to make assumptions that lets us use less code.
>
> Yes. It’s a change, but it’s one which should make the default simpler and
> more PAYG.
>
> I can do this on a branch and compile the examples. We can see how this
> effects them. Does that sound like a plan?
>
> > On Jun 6, 2018, at 6:23 PM, Alex Harui  wrote:
> >
> > This sounds scary to me because it affects the entire DOM, and not very
> PAYG.  Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
> >
> > Some other implementation options would be to:
> >
> > -Have the x,y setters set position on the parent.  I think we used to do
> this and decided to not do it anymore
> > -Have the x,y setters add a class selector to the parent.
> > -Have a bead, like we've discussed for UnselectableElement, that brings
> in the selector.
> > -Have the layouts that allow for absolute positioning set the right
> styles or selector on the parent.
> >
> > My 2 cents,
> > -Alex
> >
> > On 6/5/18, 11:44 PM, "Harbs"  wrote:
> >
> >FYI, I applied this change to my PrintUI app and it seems like we had
> applied quite a few ugly work-arounds to get things to be positioned
> correctly. We did not realize at the time that it was due to the default
> being position: static. Switching the default to position: relative
> simplifies element positioning a lot, and enables us to get rid of a lot of
> positional overrides to make things stay where they should.
> >
> >If there’s no objections, I’ll apply this change. It might require
> some changes to client apps, but this is mostly to remove work-arounds that
> shouldn’t have been required in the first place and I think it’s
> worth-while.
> >
> >The change will also enable us to get rid of forced reflow when
> setting x and y values to UIBase which is a major performance sore-spot.
> >
> >Harbs
> >
> >> On Jun 5, 2018, at 8:00 AM, Alex Harui 
> wrote:
> >>
> >> Ah, ok.  How would a user disable that selector in case it did
> something undesirable?
> >>
> >> -Alex
> >>
> >> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> >>
> >>   Sorry I was a bit confused. The selector that works is:
> >>
> >>   .Application * {
> >>  position: relative;
> >>   }
> >>
> >>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
> >>>
> >>> Yes. But it cascades down.
> >>>
> >>> I manually made this change to the TreeExample project, and it fixed
> the bug.
> >>>
>  On Jun 4, 2018, at 7:22 PM, Alex Harui 
> wrote:
> 
>  I'm still not understanding.  Style.position is not inheriting so how
> would it cascade down?  Isn't .Application only applied to the ?
> 
>  Thanks,
>  -Alex
> 
>  On 6/4/18, 9:15 AM, "Harbs"  wrote:
> 
>  I’m suggesting that we change defaults.css
> 
>  from:
>  Application
>  {
> padding: 0px;
> margin: 0px;
>  }
> 
>  to:
>  Application
>  {
> padding: 0px;
> margin: 0px;
> position: relative;
>  }
> 
>  I believe this will resolve this issue as the default would cascade
> down to all sub-elements. The default would be relative, but beads would be
> free to change that to whatever they want.
> 
>  Of course, that would dictate that UIBase belongs in Basic and not
> Core… ;-)
> 
>  Harbs
> 
> > On Jun 4, 2018, at 7:10 PM, Alex Harui 
> wrote:
> >
> > I’m not sure exactly what change you are proposing, but UIBase used
> to set position=relative on all positioners.  We took that away so that the
> "flex" and other display/layout styles would not have to deal with the
> excess clutter and overhead of having set position on so many elements in
> the DOM.  Via PAYG, only the elements that need to have a style.position
> should have it set.
> >
> > My 2 cents,
> > -Alex
> >
> > On 6/4/18, 8:44 AM, "Harbs"  wrote:
> >
> > It just occurred to me that the problem is due to the default
> position being static.
> >
> > I just added position: relative; to the .Application css and that
> resolved the issue as well.
> >
> > I wonder if we could completely do away with the offsetParent logic
> in UIBase if we make the default position: relative. That would have a
> major positive impact on performance.
> >
> > Thoughts?
> > Harbs
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi Alex

2018-06-06 17:23 GMT+02:00 Alex Harui :

> This sounds scary to me because it affects the entire DOM, and not very
> PAYG.  Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
>

What you refer exactly to try? let me know to do it .


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> ... and not very PAYG.

On the contrary.

The same way we are applying box-sizing: border-box because it is a better 
default and prevents extra processing, applying relative instead of static as a 
default allows us to make assumptions that lets us use less code.

Yes. It’s a change, but it’s one which should make the default simpler and more 
PAYG.

I can do this on a branch and compile the examples. We can see how this effects 
them. Does that sound like a plan?

> On Jun 6, 2018, at 6:23 PM, Alex Harui  wrote:
> 
> This sounds scary to me because it affects the entire DOM, and not very PAYG. 
>  Maybe Carlos should try it on his Jewel layouts and see if anything breaks.
> 
> Some other implementation options would be to:
> 
> -Have the x,y setters set position on the parent.  I think we used to do this 
> and decided to not do it anymore
> -Have the x,y setters add a class selector to the parent.
> -Have a bead, like we've discussed for UnselectableElement, that brings in 
> the selector.
> -Have the layouts that allow for absolute positioning set the right styles or 
> selector on the parent.
> 
> My 2 cents,
> -Alex
> 
> On 6/5/18, 11:44 PM, "Harbs"  wrote:
> 
>FYI, I applied this change to my PrintUI app and it seems like we had 
> applied quite a few ugly work-arounds to get things to be positioned 
> correctly. We did not realize at the time that it was due to the default 
> being position: static. Switching the default to position: relative 
> simplifies element positioning a lot, and enables us to get rid of a lot of 
> positional overrides to make things stay where they should.
> 
>If there’s no objections, I’ll apply this change. It might require some 
> changes to client apps, but this is mostly to remove work-arounds that 
> shouldn’t have been required in the first place and I think it’s worth-while.
> 
>The change will also enable us to get rid of forced reflow when setting x 
> and y values to UIBase which is a major performance sore-spot.
> 
>Harbs
> 
>> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
>> 
>> Ah, ok.  How would a user disable that selector in case it did something 
>> undesirable?
>> 
>> -Alex
>> 
>> On 6/4/18, 1:56 PM, "Harbs"  wrote:
>> 
>>   Sorry I was a bit confused. The selector that works is:
>> 
>>   .Application * {
>>  position: relative;
>>   }
>> 
>>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>>> 
>>> Yes. But it cascades down.
>>> 
>>> I manually made this change to the TreeExample project, and it fixed the 
>>> bug.
>>> 
 On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
 
 I'm still not understanding.  Style.position is not inheriting so how 
 would it cascade down?  Isn't .Application only applied to the ?
 
 Thanks,
 -Alex
 
 On 6/4/18, 9:15 AM, "Harbs"  wrote:
 
 I’m suggesting that we change defaults.css
 
 from:
 Application
 {
padding: 0px;
margin: 0px;
 }
 
 to:
 Application
 {
padding: 0px;
margin: 0px;
position: relative;
 }
 
 I believe this will resolve this issue as the default would cascade down 
 to all sub-elements. The default would be relative, but beads would be 
 free to change that to whatever they want.
 
 Of course, that would dictate that UIBase belongs in Basic and not Core… 
 ;-)
 
 Harbs
 
> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
> 
> I’m not sure exactly what change you are proposing, but UIBase used to 
> set position=relative on all positioners.  We took that away so that the 
> "flex" and other display/layout styles would not have to deal with the 
> excess clutter and overhead of having set position on so many elements in 
> the DOM.  Via PAYG, only the elements that need to have a style.position 
> should have it set.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> 
> It just occurred to me that the problem is due to the default position 
> being static.
> 
> I just added position: relative; to the .Application css and that 
> resolved the issue as well.
> 
> I wonder if we could completely do away with the offsetParent logic in 
> UIBase if we make the default position: relative. That would have a major 
> positive impact on performance.
> 
> Thoughts?
> Harbs
> 
>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>> 
>> Hi Yishay,
>> 
>> IMO, the new fix is better.  And you took the right approach by 
>> examining the code flow in the debugger.  When layout fails for what 
>> appears to be a timing issue (in this case, offsetParent not set), we 
>> definitely want to take the time to carefully analyze why there is a 
>> timing issue instead of apply code to work around the current lifecycle.
>> 
>> I'm not sure we can recommend a general pattern for layouts.  I think 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

This sounds scary to me because it affects the entire DOM, and not very PAYG.  
Maybe Carlos should try it on his Jewel layouts and see if anything breaks.

Some other implementation options would be to:

-Have the x,y setters set position on the parent.  I think we used to do this 
and decided to not do it anymore
-Have the x,y setters add a class selector to the parent.
-Have a bead, like we've discussed for UnselectableElement, that brings in the 
selector.
-Have the layouts that allow for absolute positioning set the right styles or 
selector on the parent.

My 2 cents,
-Alex

On 6/5/18, 11:44 PM, "Harbs"  wrote:

FYI, I applied this change to my PrintUI app and it seems like we had 
applied quite a few ugly work-arounds to get things to be positioned correctly. 
We did not realize at the time that it was due to the default being position: 
static. Switching the default to position: relative simplifies element 
positioning a lot, and enables us to get rid of a lot of positional overrides 
to make things stay where they should.

If there’s no objections, I’ll apply this change. It might require some 
changes to client apps, but this is mostly to remove work-arounds that 
shouldn’t have been required in the first place and I think it’s worth-while.

The change will also enable us to get rid of forced reflow when setting x 
and y values to UIBase which is a major performance sore-spot.

Harbs

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the 
bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade 
down to all sub-elements. The default would be relative, but beads would be 
free to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not 
Core… ;-)
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui  
wrote:
 
 I’m not sure exactly what change you are proposing, but UIBase used to 
set position=relative on all positioners.  We took that away so that the "flex" 
and other display/layout styles would not have to deal with the excess clutter 
and overhead of having set position on so many elements in the DOM.  Via PAYG, 
only the elements that need to have a style.position should have it set.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 8:44 AM, "Harbs"  wrote:
 
 It just occurred to me that the problem is due to the default position 
being static.
 
 I just added position: relative; to the .Application css and that 
resolved the issue as well.
 
 I wonder if we could completely do away with the offsetParent logic in 
UIBase if we make the default position: relative. That would have a major 
positive impact on performance.
 
 Thoughts?
 Harbs
 
> On Jun 4, 2018, at 6:36 PM, Alex Harui  
wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by 
examining the code flow in the debugger.  When layout fails for what appears to 
be a timing issue (in this case, offsetParent not set), we definitely want to 
take the time to carefully analyze why there is a timing issue instead of apply 
code to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think 
there is some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Yes. There is a lot to be said for your approach of using strictly classes for 
assigning layouts using CSS.

It prevents a lot of the reflowing problems.

I’m interested in seeing how far you can get with it. :-)

Harbs

> On Jun 6, 2018, at 10:58 AM, Carlos Rovira  wrote:
> 
> Hi Yishay,
> maybe mixing topics, but I only showing how I'm solving in jewel layouts.
> Why I'm creating new layouts? since I see many problems with mixing layout
> types (display: block, in other cases flex...), and seems inconsistent, so
> I'm trying to base all in Jewel in only one system. Flexbox is not the best
> (I think Grid would be better), but is supported in IE11, so is the middle
> point right now.
> A secondary motive was to get rid of JS loops or processing when possible,
> since layout and positioning nowadays is done completely in CSS, so Jewel
> layout has (for now), SWF code like in basic (can change when I reach to
> focus more on SWF part), but JS is turning to use only CSS class selectors,
> so the browsers handle all positioning. The work is still in progress, for
> now I get IE11 working again and things positioning right in all browsers,
> that is by itself a huge improvement over the jewel layout classes that we
> had some days ago. As Harbs said a collateral effect of all of this (but
> not a main one) is that we should end with "styles" set in HTML, or at
> least only use that if we want to make some dynamic change at runtime.
> 
> 
> 2018-06-06 7:52 GMT+02:00 Yishay Weiss :
> 
>> Ok, but why does that get in the way of ‘flex’ and other display/layout
>> styles?
>> 
>> 
>> 
>> ________
>> From: Alex Harui 
>> Sent: Tuesday, June 5, 2018 7:53:51 PM
>> To: dev@royale.apache.org
>> Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that
>> a proper fix?
>> 
>> If you look at the DOM generated back then, every tag had
>> "style="position:relative" on it.
>> 
>> -Alex
>> 
>> On 6/4/18, 11:53 PM, "yishayw"  wrote:
>> 
>>Alex Harui-2 wrote
>>> UIBase used to set position=relative on all positioners.  We took
>> that
>>> away so that the "flex" and other display/layout styles would not
>> have to
>>> deal with the excess clutter and overhead of having set position on
>> so
>>> many elements in the DOM.
>> 
>>Can you give an example of excess clutter caused by this?
>> 
>> 
>> 
>> 
>>--
>>Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fapache-royale-development.20373.n8.nabble.com%2F=
>> 02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab10
>> 05c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63663778392
>> 0590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi Yishay,
maybe mixing topics, but I only showing how I'm solving in jewel layouts.
Why I'm creating new layouts? since I see many problems with mixing layout
types (display: block, in other cases flex...), and seems inconsistent, so
I'm trying to base all in Jewel in only one system. Flexbox is not the best
(I think Grid would be better), but is supported in IE11, so is the middle
point right now.
A secondary motive was to get rid of JS loops or processing when possible,
since layout and positioning nowadays is done completely in CSS, so Jewel
layout has (for now), SWF code like in basic (can change when I reach to
focus more on SWF part), but JS is turning to use only CSS class selectors,
so the browsers handle all positioning. The work is still in progress, for
now I get IE11 working again and things positioning right in all browsers,
that is by itself a huge improvement over the jewel layout classes that we
had some days ago. As Harbs said a collateral effect of all of this (but
not a main one) is that we should end with "styles" set in HTML, or at
least only use that if we want to make some dynamic change at runtime.


2018-06-06 7:52 GMT+02:00 Yishay Weiss :

> Ok, but why does that get in the way of ‘flex’ and other display/layout
> styles?
>
>
>
> 
> From: Alex Harui 
> Sent: Tuesday, June 5, 2018 7:53:51 PM
> To: dev@royale.apache.org
> Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that
> a proper fix?
>
> If you look at the DOM generated back then, every tag had
> "style="position:relative" on it.
>
> -Alex
>
> On 6/4/18, 11:53 PM, "yishayw"  wrote:
>
> Alex Harui-2 wrote
> > UIBase used to set position=relative on all positioners.  We took
> that
> > away so that the "flex" and other display/layout styles would not
> have to
> > deal with the excess clutter and overhead of having set position on
> so
> > many elements in the DOM.
>
> Can you give an example of excess clutter caused by this?
>
>
>
>
> --
> Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%
> 2F%2Fapache-royale-development.20373.n8.nabble.com%2F=
> 02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab10
> 05c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63663778392
> 0590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

FYI, I applied this change to my PrintUI app and it seems like we had applied 
quite a few ugly work-arounds to get things to be positioned correctly. We did 
not realize at the time that it was due to the default being position: static. 
Switching the default to position: relative simplifies element positioning a 
lot, and enables us to get rid of a lot of positional overrides to make things 
stay where they should.

If there’s no objections, I’ll apply this change. It might require some changes 
to client apps, but this is mostly to remove work-arounds that shouldn’t have 
been required in the first place and I think it’s worth-while.

The change will also enable us to get rid of forced reflow when setting x and y 
values to UIBase which is a major performance sore-spot.

Harbs

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
> undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how would 
>>> it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade down 
>>> to all sub-elements. The default would be relative, but beads would be free 
>>> to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>> ;-)
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
 
 I’m not sure exactly what change you are proposing, but UIBase used to set 
 position=relative on all positioners.  We took that away so that the 
 "flex" and other display/layout styles would not have to deal with the 
 excess clutter and overhead of having set position on so many elements in 
 the DOM.  Via PAYG, only the elements that need to have a style.position 
 should have it set.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 8:44 AM, "Harbs"  wrote:
 
 It just occurred to me that the problem is due to the default position 
 being static.
 
 I just added position: relative; to the .Application css and that resolved 
 the issue as well.
 
 I wonder if we could completely do away with the offsetParent logic in 
 UIBase if we make the default position: relative. That would have a major 
 positive impact on performance.
 
 Thoughts?
 Harbs
 
> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by examining 
> the code flow in the debugger.  When layout fails for what appears to be 
> a timing issue (in this case, offsetParent not set), we definitely want 
> to take the time to carefully analyze why there is a timing issue instead 
> of apply code to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think 
> there is some PAYG involved.  It could be that in some cases the View 
> should be responsible for setting style.position.  Then the layouts don't 
> have to spend the time verifying style.position.  In other cases the 
> layouts could be used in places where other potential layouts don't rely 
> on style.position being a particular value.  I think BasicLayout for 
> Containers is an example.
> 
> The code you used could be put into a utility function for layouts to use 
> to guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
> Looking at it some more it has nothing to do with data binding. I pushed a
> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
> layout itself. Here it's assumed the offsetParent is explicitly set before
> children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
> --
> Sent from: 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I think the point was that the inline style needed to be removed in certain 
cases.

> On Jun 6, 2018, at 8:52 AM, Yishay Weiss  wrote:
> 
> Ok, but why does that get in the way of ‘flex’ and other display/layout 
> styles?
> 
> 
> 
> 
> From: Alex Harui 
> Sent: Tuesday, June 5, 2018 7:53:51 PM
> To: dev@royale.apache.org
> Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
> proper fix?
> 
> If you look at the DOM generated back then, every tag had 
> "style="position:relative" on it.
> 
> -Alex
> 
> On 6/4/18, 11:53 PM, "yishayw"  wrote:
> 
>Alex Harui-2 wrote
>> UIBase used to set position=relative on all positioners.  We took that
>> away so that the "flex" and other display/layout styles would not have to
>> deal with the excess clutter and overhead of having set position on so
>> many elements in the DOM.
> 
>Can you give an example of excess clutter caused by this?
> 
> 
> 
> 
>--
>Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab1005c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637783920590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0
> 
> 

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

Ok, but why does that get in the way of ‘flex’ and other display/layout styles?




From: Alex Harui 
Sent: Tuesday, June 5, 2018 7:53:51 PM
To: dev@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

If you look at the DOM generated back then, every tag had 
"style="position:relative" on it.

-Alex

On 6/4/18, 11:53 PM, "yishayw"  wrote:

Alex Harui-2 wrote
> UIBase used to set position=relative on all positioners.  We took that
> away so that the "flex" and other display/layout styles would not have to
> deal with the excess clutter and overhead of having set position on so
> many elements in the DOM.

Can you give an example of excess clutter caused by this?




--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab1005c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637783920590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi Alex,


2018-06-05 18:31 GMT+02:00 Alex Harui :

> They might be connected.  I think the problem we've been discussing is
> "how should the DOM be set up for absolute positioning?".


in Jewel I'm trying to use only flexbox, and that's part of Jewel. So both,
classes and css rules are defined in Jewel SWC. So themes not handle layout
and positioning only drawings, borders, backgrounds, colors, fonts...


> I don't think there is a perfect solution, but using '.Application *' may
> be good enough for now.
>

yes I think so the base of all of this is:

.layout
display: flex

.layout.absolute
position: relative
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
> *
position: absolute

.layout.horizontal
flex-flow: row nowrap
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
align-items: flex-start

.layout.vertical
flex-flow: column nowrap
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
align-items: flex-start


In this way we get layouts working flawlessly for IE11, Chrome, Firefox,
Safari, Opera ...
(since Grid is still not so widely supported).


> I think you may be describing a different issue which is "how should
> layouts find out about the need to run layout again?".  I don't think there
> is a right answer here either, but PAYG says we shouldn't bake in watching
> every child in the DOM like Flex did.  That's just wasteful.  We could
> create some bead that does that for the general case, or for Express and
> maybe even Jewel to cut down on configuration/debugging, but we should make
> sure other strategies work, like beads that watch a single property on a
> component (LayoutChangeNotifier).  The idea is that someone should only
> have to pay for watching the things that truly matter in layout.
>

Right, I think I still need to remove the sizeChange event in BasicLayout
and maybe do a bead for basic layout bead... for example a
"NotifySizeChange" bead that will loop over child items and dispatch the
event
thoughts?


>
> My 2 cents,
> -Alex
>
> On 6/5/18, 4:15 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi,
>
> just let you know that the problem seems a bit close to the one I
> reported
> about using view states for a new blog example post.
> If I change View layout from Basic to for example VerticalLayout, that
> fixes the issue.
> So in Jewel BasicLayout, that now is based on CSS, I added a loop like
> in
> the rest of layouts so each chid dispatch "sizeChanged" event
> This fixes the problem.
> So maybe this is not the right fix, but seems that basic layout needs
> its
> children to "prepare" itself for a change.
>
> Just to let you know since it seems both problems are connected.
>
> Thanks
>
>
> 2018-06-05 8:53 GMT+02:00 yishayw :
>
> > Alex Harui-2 wrote
> > > UIBase used to set position=relative on all positioners.  We took
> that
> > > away so that the "flex" and other display/layout styles would not
> have to
> > > deal with the excess clutter and overhead of having set position
> on so
> > > many elements in the DOM.
> >
> > Can you give an example of excess clutter caused by this?
> >
> >
> >
> >
> > --
> > Sent from: https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-royale-development.20373.n8.nabble.
> com%2F=02%7C01%7Caharui%40adobe.com%7C7544e7d51bcd4246635e08d5cad5
> a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636637941374916636=rt9%2BTvmMTxoONKGPs28eeW7BBjZ85Fic
> saMk7ygxno0%3D=0
> >
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636637941374916636=y%2BAUMUakdOYIoVnc1NOYB96AbqgIuz
> BUoGzQXE6XCLA%3D=0
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

If you look at the DOM generated back then, every tag had 
"style="position:relative" on it.

-Alex

On 6/4/18, 11:53 PM, "yishayw"  wrote:

Alex Harui-2 wrote
> UIBase used to set position=relative on all positioners.  We took that
> away so that the "flex" and other display/layout styles would not have to
> deal with the excess clutter and overhead of having set position on so
> many elements in the DOM. 

Can you give an example of excess clutter caused by this?




--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab1005c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637783920590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

They might be connected.  I think the problem we've been discussing is "how 
should the DOM be set up for absolute positioning?".  I don't think there is a 
perfect solution, but using '.Application *' may be good enough for now.

I think you may be describing a different issue which is "how should layouts 
find out about the need to run layout again?".  I don't think there is a right 
answer here either, but PAYG says we shouldn't bake in watching every child in 
the DOM like Flex did.  That's just wasteful.  We could create some bead that 
does that for the general case, or for Express and maybe even Jewel to cut down 
on configuration/debugging, but we should make sure other strategies work, like 
beads that watch a single property on a component (LayoutChangeNotifier).  The 
idea is that someone should only have to pay for watching the things that truly 
matter in layout.

My 2 cents,
-Alex

On 6/5/18, 4:15 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi,

just let you know that the problem seems a bit close to the one I reported
about using view states for a new blog example post.
If I change View layout from Basic to for example VerticalLayout, that
fixes the issue.
So in Jewel BasicLayout, that now is based on CSS, I added a loop like in
the rest of layouts so each chid dispatch "sizeChanged" event
This fixes the problem.
So maybe this is not the right fix, but seems that basic layout needs its
children to "prepare" itself for a change.

Just to let you know since it seems both problems are connected.

Thanks


2018-06-05 8:53 GMT+02:00 yishayw :

> Alex Harui-2 wrote
> > UIBase used to set position=relative on all positioners.  We took that
> > away so that the "flex" and other display/layout styles would not have 
to
> > deal with the excess clutter and overhead of having set position on so
> > many elements in the DOM.
>
> Can you give an example of excess clutter caused by this?
>
>
>
>
> --
> Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637941374916636=rt9%2BTvmMTxoONKGPs28eeW7BBjZ85FicsaMk7ygxno0%3D=0
>



-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637941374916636=y%2BAUMUakdOYIoVnc1NOYB96AbqgIuzBUoGzQXE6XCLA%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi,

just let you know that the problem seems a bit close to the one I reported
about using view states for a new blog example post.
If I change View layout from Basic to for example VerticalLayout, that
fixes the issue.
So in Jewel BasicLayout, that now is based on CSS, I added a loop like in
the rest of layouts so each chid dispatch "sizeChanged" event
This fixes the problem.
So maybe this is not the right fix, but seems that basic layout needs its
children to "prepare" itself for a change.

Just to let you know since it seems both problems are connected.

Thanks


2018-06-05 8:53 GMT+02:00 yishayw :

> Alex Harui-2 wrote
> > UIBase used to set position=relative on all positioners.  We took that
> > away so that the "flex" and other display/layout styles would not have to
> > deal with the excess clutter and overhead of having set position on so
> > many elements in the DOM.
>
> Can you give an example of excess clutter caused by this?
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[yishayw]

Alex Harui-2 wrote
> UIBase used to set position=relative on all positioners.  We took that
> away so that the "flex" and other display/layout styles would not have to
> deal with the excess clutter and overhead of having set position on so
> many elements in the DOM. 

Can you give an example of excess clutter caused by this?




--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Yeah. If you’d need static for some reason, you’d specify that. I think needing 
static instead of relative would be pretty rare. Here’s an interesting 
article.[1]

I think the fact that static is the default in HTML is more of conceptual 
decision (less opinion on positioning) than a practical one (static leads to 
unexpected layout).

Even describing what static does is complicated as opposed to relative which is 
conceptually simple.[2]

All in all, relative seems like the right default for Royale apps to have.

My $0.02,
Harbs

[1]https://css-tricks.com/what-if-there-was-no-position-static/ 

[2]https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document
 


> On Jun 5, 2018, at 8:23 AM, Alex Harui  wrote:
> 
> What I'm wondering is how you would make it so it was as if that selector 
> wasn't specified at all.  I guess the default value for position is "static" 
> so the user would specify position: static?
> 
> -Alex
> 
> On 6/4/18, 10:03 PM, "Harbs"  wrote:
> 
>Any other selector should disable that one because that’s about as 
> unspecific as you can get and the higher level of specificity always wins.
> 
>> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
>> 
>> Ah, ok.  How would a user disable that selector in case it did something 
>> undesirable?
>> 
>> -Alex
>> 
>> On 6/4/18, 1:56 PM, "Harbs"  wrote:
>> 
>>   Sorry I was a bit confused. The selector that works is:
>> 
>>   .Application * {
>>  position: relative;
>>   }
>> 
>>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>>> 
>>> Yes. But it cascades down.
>>> 
>>> I manually made this change to the TreeExample project, and it fixed the 
>>> bug.
>>> 
 On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
 
 I'm still not understanding.  Style.position is not inheriting so how 
 would it cascade down?  Isn't .Application only applied to the ?
 
 Thanks,
 -Alex
 
 On 6/4/18, 9:15 AM, "Harbs"  wrote:
 
 I’m suggesting that we change defaults.css
 
 from:
 Application
 {
padding: 0px;
margin: 0px;
 }
 
 to:
 Application
 {
padding: 0px;
margin: 0px;
position: relative;
 }
 
 I believe this will resolve this issue as the default would cascade down 
 to all sub-elements. The default would be relative, but beads would be 
 free to change that to whatever they want.
 
 Of course, that would dictate that UIBase belongs in Basic and not Core… 
 ;-)
 
 Harbs
 
> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
> 
> I’m not sure exactly what change you are proposing, but UIBase used to 
> set position=relative on all positioners.  We took that away so that the 
> "flex" and other display/layout styles would not have to deal with the 
> excess clutter and overhead of having set position on so many elements in 
> the DOM.  Via PAYG, only the elements that need to have a style.position 
> should have it set.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> 
> It just occurred to me that the problem is due to the default position 
> being static.
> 
> I just added position: relative; to the .Application css and that 
> resolved the issue as well.
> 
> I wonder if we could completely do away with the offsetParent logic in 
> UIBase if we make the default position: relative. That would have a major 
> positive impact on performance.
> 
> Thoughts?
> Harbs
> 
>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>> 
>> Hi Yishay,
>> 
>> IMO, the new fix is better.  And you took the right approach by 
>> examining the code flow in the debugger.  When layout fails for what 
>> appears to be a timing issue (in this case, offsetParent not set), we 
>> definitely want to take the time to carefully analyze why there is a 
>> timing issue instead of apply code to work around the current lifecycle.
>> 
>> I'm not sure we can recommend a general pattern for layouts.  I think 
>> there is some PAYG involved.  It could be that in some cases the View 
>> should be responsible for setting style.position.  Then the layouts 
>> don't have to spend the time verifying style.position.  In other cases 
>> the layouts could be used in places where other potential layouts don't 
>> rely on style.position being a particular value.  I think BasicLayout 
>> for Containers is an example.
>> 
>> The code you used could be put into a utility function for layouts to 
>> use to guarantee that x,y will work as expected.
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 8:22 AM, 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

What I'm wondering is how you would make it so it was as if that selector 
wasn't specified at all.  I guess the default value for position is "static" so 
the user would specify position: static?

-Alex

On 6/4/18, 10:03 PM, "Harbs"  wrote:

Any other selector should disable that one because that’s about as 
unspecific as you can get and the higher level of specificity always wins.

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the 
bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade 
down to all sub-elements. The default would be relative, but beads would be 
free to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not 
Core… ;-)
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui  
wrote:
 
 I’m not sure exactly what change you are proposing, but UIBase used to 
set position=relative on all positioners.  We took that away so that the "flex" 
and other display/layout styles would not have to deal with the excess clutter 
and overhead of having set position on so many elements in the DOM.  Via PAYG, 
only the elements that need to have a style.position should have it set.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 8:44 AM, "Harbs"  wrote:
 
 It just occurred to me that the problem is due to the default position 
being static.
 
 I just added position: relative; to the .Application css and that 
resolved the issue as well.
 
 I wonder if we could completely do away with the offsetParent logic in 
UIBase if we make the default position: relative. That would have a major 
positive impact on performance.
 
 Thoughts?
 Harbs
 
> On Jun 4, 2018, at 6:36 PM, Alex Harui  
wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by 
examining the code flow in the debugger.  When layout fails for what appears to 
be a timing issue (in this case, offsetParent not set), we definitely want to 
take the time to carefully analyze why there is a timing issue instead of apply 
code to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think 
there is some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.
> 
> The code you used could be put into a utility function for layouts to 
use to guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
> Looking at it some more it has nothing to do with data binding. I 
pushed a
> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes 
the
> layout itself. Here it's assumed the offsetParent is explicitly set 
before
> children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
> --
> Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Any other selector should disable that one because that’s about as unspecific 
as you can get and the higher level of specificity always wins.

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
> undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how would 
>>> it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade down 
>>> to all sub-elements. The default would be relative, but beads would be free 
>>> to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>> ;-)
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
 
 I’m not sure exactly what change you are proposing, but UIBase used to set 
 position=relative on all positioners.  We took that away so that the 
 "flex" and other display/layout styles would not have to deal with the 
 excess clutter and overhead of having set position on so many elements in 
 the DOM.  Via PAYG, only the elements that need to have a style.position 
 should have it set.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 8:44 AM, "Harbs"  wrote:
 
 It just occurred to me that the problem is due to the default position 
 being static.
 
 I just added position: relative; to the .Application css and that resolved 
 the issue as well.
 
 I wonder if we could completely do away with the offsetParent logic in 
 UIBase if we make the default position: relative. That would have a major 
 positive impact on performance.
 
 Thoughts?
 Harbs
 
> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by examining 
> the code flow in the debugger.  When layout fails for what appears to be 
> a timing issue (in this case, offsetParent not set), we definitely want 
> to take the time to carefully analyze why there is a timing issue instead 
> of apply code to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think 
> there is some PAYG involved.  It could be that in some cases the View 
> should be responsible for setting style.position.  Then the layouts don't 
> have to spend the time verifying style.position.  In other cases the 
> layouts could be used in places where other potential layouts don't rely 
> on style.position being a particular value.  I think BasicLayout for 
> Containers is an example.
> 
> The code you used could be put into a utility function for layouts to use 
> to guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
> Looking at it some more it has nothing to do with data binding. I pushed a
> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
> layout itself. Here it's assumed the offsetParent is explicitly set before
> children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
> --
> Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

This looks ok to me. As I understand it [1] the only difference between 
position: static (which is the default) and position: relative is that they 
don’t obey left, top, bottom, right rules. Since Royale won’t be injecting 
unintended offset values, the default behavior shouldn’t change.



[1] 
https://stackoverflow.com/questions/5011211/difference-between-static-and-relative-positioning




From: Harbs 
Sent: Monday, June 4, 2018 11:55:52 PM
To: dev@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>
> Yes. But it cascades down.
>
> I manually made this change to the TreeExample project, and it fixed the bug.
>
>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>
>> I'm still not understanding.  Style.position is not inheriting so how would 
>> it cascade down?  Isn't .Application only applied to the ?
>>
>> Thanks,
>> -Alex
>>
>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>
>>   I’m suggesting that we change defaults.css
>>
>>   from:
>>   Application
>>   {
>>   padding: 0px;
>>   margin: 0px;
>>   }
>>
>>   to:
>>   Application
>>   {
>>   padding: 0px;
>>   margin: 0px;
>>   position: relative;
>>   }
>>
>>   I believe this will resolve this issue as the default would cascade down 
>> to all sub-elements. The default would be relative, but beads would be free 
>> to change that to whatever they want.
>>
>>   Of course, that would dictate that UIBase belongs in Basic and not Core… 
>> ;-)
>>
>>   Harbs
>>
>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>>
>>> I’m not sure exactly what change you are proposing, but UIBase used to set 
>>> position=relative on all positioners.  We took that away so that the "flex" 
>>> and other display/layout styles would not have to deal with the excess 
>>> clutter and overhead of having set position on so many elements in the DOM. 
>>>  Via PAYG, only the elements that need to have a style.position should have 
>>> it set.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>
>>>  It just occurred to me that the problem is due to the default position 
>>> being static.
>>>
>>>  I just added position: relative; to the .Application css and that resolved 
>>> the issue as well.
>>>
>>>  I wonder if we could completely do away with the offsetParent logic in 
>>> UIBase if we make the default position: relative. That would have a major 
>>> positive impact on performance.
>>>
>>>  Thoughts?
>>>  Harbs
>>>
>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>>>>
>>>> Hi Yishay,
>>>>
>>>> IMO, the new fix is better.  And you took the right approach by examining 
>>>> the code flow in the debugger.  When layout fails for what appears to be a 
>>>> timing issue (in this case, offsetParent not set), we definitely want to 
>>>> take the time to carefully analyze why there is a timing issue instead of 
>>>> apply code to work around the current lifecycle.
>>>>
>>>> I'm not sure we can recommend a general pattern for layouts.  I think 
>>>> there is some PAYG involved.  It could be that in some cases the View 
>>>> should be responsible for setting style.position.  Then the layouts don't 
>>>> have to spend the time verifying style.position.  In other cases the 
>>>> layouts could be used in places where other potential layouts don't rely 
>>>> on style.position being a particular value.  I think BasicLayout for 
>>>> Containers is an example.
>>>>
>>>> The code you used could be put into a utility function for layouts to use 
>>>> to guarantee that x,y will work as expected.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>>>>
>>>> Looking at it some more it has nothing to do with data binding. I pushed a
>>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>>>> layout itself. Here it's assumed the offsetParent is explicitly set before
>>>> children's x and y are set. Should this be a general pattern?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Ah, ok.  How would a user disable that selector in case it did something 
undesirable?

-Alex

On 6/4/18, 1:56 PM, "Harbs"  wrote:

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
> 
> Yes. But it cascades down.
> 
> I manually made this change to the TreeExample project, and it fixed the 
bug.
> 
>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>> 
>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>> 
>>   I’m suggesting that we change defaults.css
>> 
>>   from:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>   }
>> 
>>   to:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>  position: relative;
>>   }
>> 
>>   I believe this will resolve this issue as the default would cascade 
down to all sub-elements. The default would be relative, but beads would be 
free to change that to whatever they want.
>> 
>>   Of course, that would dictate that UIBase belongs in Basic and not 
Core… ;-)
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>> 
>>> I’m not sure exactly what change you are proposing, but UIBase used to 
set position=relative on all positioners.  We took that away so that the "flex" 
and other display/layout styles would not have to deal with the excess clutter 
and overhead of having set position on so many elements in the DOM.  Via PAYG, 
only the elements that need to have a style.position should have it set.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>> 
>>>  It just occurred to me that the problem is due to the default position 
being static.
>>> 
>>>  I just added position: relative; to the .Application css and that 
resolved the issue as well.
>>> 
>>>  I wonder if we could completely do away with the offsetParent logic in 
UIBase if we make the default position: relative. That would have a major 
positive impact on performance.
>>> 
>>>  Thoughts?
>>>  Harbs
>>> 
 On Jun 4, 2018, at 6:36 PM, Alex Harui  
wrote:
 
 Hi Yishay,
 
 IMO, the new fix is better.  And you took the right approach by 
examining the code flow in the debugger.  When layout fails for what appears to 
be a timing issue (in this case, offsetParent not set), we definitely want to 
take the time to carefully analyze why there is a timing issue instead of apply 
code to work around the current lifecycle.
 
 I'm not sure we can recommend a general pattern for layouts.  I think 
there is some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.
 
 The code you used could be put into a utility function for layouts to 
use to guarantee that x,y will work as expected.
 
 Thanks,
 -Alex
 
 On 6/4/18, 8:22 AM, "yishayw"  wrote:
 
 Looking at it some more it has nothing to do with data binding. I 
pushed a
 different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes 
the
 layout itself. Here it's assumed the offsetParent is explicitly set 
before
 children's x and y are set. Should this be a general pattern?
 
 
 
 
 --
 Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
 
 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
> 
> Yes. But it cascades down.
> 
> I manually made this change to the TreeExample project, and it fixed the bug.
> 
>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>> 
>> I'm still not understanding.  Style.position is not inheriting so how would 
>> it cascade down?  Isn't .Application only applied to the ?
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>> 
>>   I’m suggesting that we change defaults.css
>> 
>>   from:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>   }
>> 
>>   to:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>  position: relative;
>>   }
>> 
>>   I believe this will resolve this issue as the default would cascade down 
>> to all sub-elements. The default would be relative, but beads would be free 
>> to change that to whatever they want.
>> 
>>   Of course, that would dictate that UIBase belongs in Basic and not Core… 
>> ;-)
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>> 
>>> I’m not sure exactly what change you are proposing, but UIBase used to set 
>>> position=relative on all positioners.  We took that away so that the "flex" 
>>> and other display/layout styles would not have to deal with the excess 
>>> clutter and overhead of having set position on so many elements in the DOM. 
>>>  Via PAYG, only the elements that need to have a style.position should have 
>>> it set.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>> 
>>>  It just occurred to me that the problem is due to the default position 
>>> being static.
>>> 
>>>  I just added position: relative; to the .Application css and that resolved 
>>> the issue as well.
>>> 
>>>  I wonder if we could completely do away with the offsetParent logic in 
>>> UIBase if we make the default position: relative. That would have a major 
>>> positive impact on performance.
>>> 
>>>  Thoughts?
>>>  Harbs
>>> 
 On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
 
 Hi Yishay,
 
 IMO, the new fix is better.  And you took the right approach by examining 
 the code flow in the debugger.  When layout fails for what appears to be a 
 timing issue (in this case, offsetParent not set), we definitely want to 
 take the time to carefully analyze why there is a timing issue instead of 
 apply code to work around the current lifecycle.
 
 I'm not sure we can recommend a general pattern for layouts.  I think 
 there is some PAYG involved.  It could be that in some cases the View 
 should be responsible for setting style.position.  Then the layouts don't 
 have to spend the time verifying style.position.  In other cases the 
 layouts could be used in places where other potential layouts don't rely 
 on style.position being a particular value.  I think BasicLayout for 
 Containers is an example.
 
 The code you used could be put into a utility function for layouts to use 
 to guarantee that x,y will work as expected.
 
 Thanks,
 -Alex
 
 On 6/4/18, 8:22 AM, "yishayw"  wrote:
 
 Looking at it some more it has nothing to do with data binding. I pushed a
 different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
 layout itself. Here it's assumed the offsetParent is explicitly set before
 children's x and y are set. Should this be a general pattern?
 
 
 
 
 --
 Sent from: 
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
 
 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

No. It’s one css selector in the CSS. No inline styles.

> On Jun 4, 2018, at 11:38 PM, Piotr Zarzycki  wrote:
> 
> Doing that does this mean that we are getting back to the previous state,
> where we have had position=relative everywhere ?
> 
> pon., 4 cze 2018 o 22:32 Harbs  napisał(a):
> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the
>> bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how
>> would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>   I’m suggesting that we change defaults.css
>>> 
>>>   from:
>>>   Application
>>>   {
>>>  padding: 0px;
>>>  margin: 0px;
>>>   }
>>> 
>>>   to:
>>>   Application
>>>   {
>>>  padding: 0px;
>>>  margin: 0px;
>>>  position: relative;
>>>   }
>>> 
>>>   I believe this will resolve this issue as the default would cascade
>> down to all sub-elements. The default would be relative, but beads would be
>> free to change that to whatever they want.
>>> 
>>>   Of course, that would dictate that UIBase belongs in Basic and not
>> Core… ;-)
>>> 
>>>   Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui 
>> wrote:
 
 I’m not sure exactly what change you are proposing, but UIBase used to
>> set position=relative on all positioners.  We took that away so that the
>> "flex" and other display/layout styles would not have to deal with the
>> excess clutter and overhead of having set position on so many elements in
>> the DOM.  Via PAYG, only the elements that need to have a style.position
>> should have it set.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 8:44 AM, "Harbs"  wrote:
 
  It just occurred to me that the problem is due to the default
>> position being static.
 
  I just added position: relative; to the .Application css and that
>> resolved the issue as well.
 
  I wonder if we could completely do away with the offsetParent logic
>> in UIBase if we make the default position: relative. That would have a
>> major positive impact on performance.
 
  Thoughts?
  Harbs
 
> On Jun 4, 2018, at 6:36 PM, Alex Harui 
>> wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by
>> examining the code flow in the debugger.  When layout fails for what
>> appears to be a timing issue (in this case, offsetParent not set), we
>> definitely want to take the time to carefully analyze why there is a timing
>> issue instead of apply code to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think
>> there is some PAYG involved.  It could be that in some cases the View
>> should be responsible for setting style.position.  Then the layouts don't
>> have to spend the time verifying style.position.  In other cases the
>> layouts could be used in places where other potential layouts don't rely on
>> style.position being a particular value.  I think BasicLayout for
>> Containers is an example.
> 
> The code you used could be put into a utility function for layouts to
>> use to guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
> Looking at it some more it has nothing to do with data binding. I
>> pushed a
> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes
>> the
> layout itself. Here it's assumed the offsetParent is explicitly set
>> before
> children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
> --
> Sent from:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Piotr Zarzycki]

Doing that does this mean that we are getting back to the previous state,
where we have had position=relative everywhere ?

pon., 4 cze 2018 o 22:32 Harbs  napisał(a):

> Yes. But it cascades down.
>
> I manually made this change to the TreeExample project, and it fixed the
> bug.
>
> > On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
> >
> > I'm still not understanding.  Style.position is not inheriting so how
> would it cascade down?  Isn't .Application only applied to the ?
> >
> > Thanks,
> > -Alex
> >
> > On 6/4/18, 9:15 AM, "Harbs"  wrote:
> >
> >I’m suggesting that we change defaults.css
> >
> >from:
> >Application
> >{
> >   padding: 0px;
> >   margin: 0px;
> >}
> >
> >to:
> >Application
> >{
> >   padding: 0px;
> >   margin: 0px;
> >   position: relative;
> >}
> >
> >I believe this will resolve this issue as the default would cascade
> down to all sub-elements. The default would be relative, but beads would be
> free to change that to whatever they want.
> >
> >Of course, that would dictate that UIBase belongs in Basic and not
> Core… ;-)
> >
> >Harbs
> >
> >> On Jun 4, 2018, at 7:10 PM, Alex Harui 
> wrote:
> >>
> >> I’m not sure exactly what change you are proposing, but UIBase used to
> set position=relative on all positioners.  We took that away so that the
> "flex" and other display/layout styles would not have to deal with the
> excess clutter and overhead of having set position on so many elements in
> the DOM.  Via PAYG, only the elements that need to have a style.position
> should have it set.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> >>
> >>   It just occurred to me that the problem is due to the default
> position being static.
> >>
> >>   I just added position: relative; to the .Application css and that
> resolved the issue as well.
> >>
> >>   I wonder if we could completely do away with the offsetParent logic
> in UIBase if we make the default position: relative. That would have a
> major positive impact on performance.
> >>
> >>   Thoughts?
> >>   Harbs
> >>
> >>> On Jun 4, 2018, at 6:36 PM, Alex Harui 
> wrote:
> >>>
> >>> Hi Yishay,
> >>>
> >>> IMO, the new fix is better.  And you took the right approach by
> examining the code flow in the debugger.  When layout fails for what
> appears to be a timing issue (in this case, offsetParent not set), we
> definitely want to take the time to carefully analyze why there is a timing
> issue instead of apply code to work around the current lifecycle.
> >>>
> >>> I'm not sure we can recommend a general pattern for layouts.  I think
> there is some PAYG involved.  It could be that in some cases the View
> should be responsible for setting style.position.  Then the layouts don't
> have to spend the time verifying style.position.  In other cases the
> layouts could be used in places where other potential layouts don't rely on
> style.position being a particular value.  I think BasicLayout for
> Containers is an example.
> >>>
> >>> The code you used could be put into a utility function for layouts to
> use to guarantee that x,y will work as expected.
> >>>
> >>> Thanks,
> >>> -Alex
> >>>
> >>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> >>>
> >>>  Looking at it some more it has nothing to do with data binding. I
> pushed a
> >>>  different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes
> the
> >>>  layout itself. Here it's assumed the offsetParent is explicitly set
> before
> >>>  children's x and y are set. Should this be a general pattern?
> >>>
> >>>
> >>>
> >>>
> >>>  --
> >>>  Sent from:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

I'm still not understanding.  Style.position is not inheriting so how would it 
cascade down?  Isn't .Application only applied to the ?

Thanks,
-Alex

On 6/4/18, 9:15 AM, "Harbs"  wrote:

I’m suggesting that we change defaults.css

from:
Application
{
padding: 0px;
margin: 0px;
}

to:
Application
{
padding: 0px;
margin: 0px;
position: relative;
}

I believe this will resolve this issue as the default would cascade down to 
all sub-elements. The default would be relative, but beads would be free to 
change that to whatever they want.

Of course, that would dictate that UIBase belongs in Basic and not Core… ;-)

Harbs

> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
> 
> I’m not sure exactly what change you are proposing, but UIBase used to 
set position=relative on all positioners.  We took that away so that the "flex" 
and other display/layout styles would not have to deal with the excess clutter 
and overhead of having set position on so many elements in the DOM.  Via PAYG, 
only the elements that need to have a style.position should have it set.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> 
>It just occurred to me that the problem is due to the default position 
being static.
> 
>I just added position: relative; to the .Application css and that 
resolved the issue as well.
> 
>I wonder if we could completely do away with the offsetParent logic in 
UIBase if we make the default position: relative. That would have a major 
positive impact on performance.
> 
>Thoughts?
>Harbs
> 
>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>> 
>> Hi Yishay,
>> 
>> IMO, the new fix is better.  And you took the right approach by 
examining the code flow in the debugger.  When layout fails for what appears to 
be a timing issue (in this case, offsetParent not set), we definitely want to 
take the time to carefully analyze why there is a timing issue instead of apply 
code to work around the current lifecycle.
>> 
>> I'm not sure we can recommend a general pattern for layouts.  I think 
there is some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.
>> 
>> The code you used could be put into a utility function for layouts to 
use to guarantee that x,y will work as expected.
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>> 
>>   Looking at it some more it has nothing to do with data binding. I 
pushed a
>>   different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes 
the
>>   layout itself. Here it's assumed the offsetParent is explicitly set 
before
>>   children's x and y are set. Should this be a general pattern?
>> 
>> 
>> 
>> 
>>   --
>>   Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>> 
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I’m suggesting that we change defaults.css

from:
Application
{
padding: 0px;
margin: 0px;
}

to:
Application
{
padding: 0px;
margin: 0px;
position: relative;
}

I believe this will resolve this issue as the default would cascade down to all 
sub-elements. The default would be relative, but beads would be free to change 
that to whatever they want.

Of course, that would dictate that UIBase belongs in Basic and not Core… ;-)

Harbs

> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
> 
> I’m not sure exactly what change you are proposing, but UIBase used to set 
> position=relative on all positioners.  We took that away so that the "flex" 
> and other display/layout styles would not have to deal with the excess 
> clutter and overhead of having set position on so many elements in the DOM.  
> Via PAYG, only the elements that need to have a style.position should have it 
> set.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> 
>It just occurred to me that the problem is due to the default position 
> being static.
> 
>I just added position: relative; to the .Application css and that resolved 
> the issue as well.
> 
>I wonder if we could completely do away with the offsetParent logic in 
> UIBase if we make the default position: relative. That would have a major 
> positive impact on performance.
> 
>Thoughts?
>Harbs
> 
>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>> 
>> Hi Yishay,
>> 
>> IMO, the new fix is better.  And you took the right approach by examining 
>> the code flow in the debugger.  When layout fails for what appears to be a 
>> timing issue (in this case, offsetParent not set), we definitely want to 
>> take the time to carefully analyze why there is a timing issue instead of 
>> apply code to work around the current lifecycle.
>> 
>> I'm not sure we can recommend a general pattern for layouts.  I think there 
>> is some PAYG involved.  It could be that in some cases the View should be 
>> responsible for setting style.position.  Then the layouts don't have to 
>> spend the time verifying style.position.  In other cases the layouts could 
>> be used in places where other potential layouts don't rely on style.position 
>> being a particular value.  I think BasicLayout for Containers is an example.
>> 
>> The code you used could be put into a utility function for layouts to use to 
>> guarantee that x,y will work as expected.
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>> 
>>   Looking at it some more it has nothing to do with data binding. I pushed a
>>   different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>>   layout itself. Here it's assumed the offsetParent is explicitly set before
>>   children's x and y are set. Should this be a general pattern?
>> 
>> 
>> 
>> 
>>   --
>>   Sent from: 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>> 
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

I’m not sure exactly what change you are proposing, but UIBase used to set 
position=relative on all positioners.  We took that away so that the "flex" and 
other display/layout styles would not have to deal with the excess clutter and 
overhead of having set position on so many elements in the DOM.  Via PAYG, only 
the elements that need to have a style.position should have it set.

My 2 cents,
-Alex

On 6/4/18, 8:44 AM, "Harbs"  wrote:

It just occurred to me that the problem is due to the default position 
being static.

I just added position: relative; to the .Application css and that resolved 
the issue as well.

I wonder if we could completely do away with the offsetParent logic in 
UIBase if we make the default position: relative. That would have a major 
positive impact on performance.

Thoughts?
Harbs

> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by examining 
the code flow in the debugger.  When layout fails for what appears to be a 
timing issue (in this case, offsetParent not set), we definitely want to take 
the time to carefully analyze why there is a timing issue instead of apply code 
to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think 
there is some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.
> 
> The code you used could be put into a utility function for layouts to use 
to guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
>Looking at it some more it has nothing to do with data binding. I 
pushed a
>different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes 
the
>layout itself. Here it's assumed the offsetParent is explicitly set 
before
>children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
>--
>Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

It just occurred to me that the problem is due to the default position being 
static.

I just added position: relative; to the .Application css and that resolved the 
issue as well.

I wonder if we could completely do away with the offsetParent logic in UIBase 
if we make the default position: relative. That would have a major positive 
impact on performance.

Thoughts?
Harbs

> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by examining the 
> code flow in the debugger.  When layout fails for what appears to be a timing 
> issue (in this case, offsetParent not set), we definitely want to take the 
> time to carefully analyze why there is a timing issue instead of apply code 
> to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think there 
> is some PAYG involved.  It could be that in some cases the View should be 
> responsible for setting style.position.  Then the layouts don't have to spend 
> the time verifying style.position.  In other cases the layouts could be used 
> in places where other potential layouts don't rely on style.position being a 
> particular value.  I think BasicLayout for Containers is an example.
> 
> The code you used could be put into a utility function for layouts to use to 
> guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
>Looking at it some more it has nothing to do with data binding. I pushed a
>different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>layout itself. Here it's assumed the offsetParent is explicitly set before
>children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
>--
>Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Alex Harui]

Hi Yishay,

IMO, the new fix is better.  And you took the right approach by examining the 
code flow in the debugger.  When layout fails for what appears to be a timing 
issue (in this case, offsetParent not set), we definitely want to take the time 
to carefully analyze why there is a timing issue instead of apply code to work 
around the current lifecycle.

I'm not sure we can recommend a general pattern for layouts.  I think there is 
some PAYG involved.  It could be that in some cases the View should be 
responsible for setting style.position.  Then the layouts don't have to spend 
the time verifying style.position.  In other cases the layouts could be used in 
places where other potential layouts don't rely on style.position being a 
particular value.  I think BasicLayout for Containers is an example.

The code you used could be put into a utility function for layouts to use to 
guarantee that x,y will work as expected.

Thanks,
-Alex

On 6/4/18, 8:22 AM, "yishayw"  wrote:

Looking at it some more it has nothing to do with data binding. I pushed a
different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
layout itself. Here it's assumed the offsetParent is explicitly set before
children's x and y are set. Should this be a general pattern?




--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[yishayw]

Looking at it some more it has nothing to do with data binding. I pushed a
different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
layout itself. Here it's assumed the offsetParent is explicitly set before
children's x and y are set. Should this be a general pattern?




--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[yishayw]

Carlos Rovira-2 wrote
> this seems like a bug to be fixed at the core of the component, or the
> layout system.

It could be that data binding is messing it up, and that the data provider
change triggers the layout before the rest of the components can probably
size themselves. I need to look a bit deeper.


Carlos Rovira-2 wrote
> for me I'll prefer to
> discuss in mailing list, since GitHub pages seems more like a reference
> site, more than a discussion place.

Maybe if I changed the title to 'migrating from Flex layouts' it would fit
better in the Wiki. My intent was to share some of the problems I
encountered, explain the Royale (Basic) way of tackling them, and open up
discussion on whether or not the Royale way makes sense.


Carlos Rovira-2 wrote
> important changes to jewel layouts, I want to fix some left things and
> write about it to let you all know what's all about.

Sounds good.


2018-06-03 12:21 GMT+02:00 Yishay Weiss yishayjobs@:

> This could be a good topic to put down here…
>
> https://github.com/apache/royale-asjs/wiki/Layout-Challenges
>
>
> 
> From: Yishay Weiss yishayjobs@
> Sent: Sunday, June 3, 2018 1:18:03 PM
> To: dev@.apache
> Subject: RE: [royale-asjs] branch develop updated: Fixes #258. But is that
> a proper fix?
>
> I’ve seen several instances where the offsetParent hasn’t been set yet
> when layout is run, which messes things up. I solved this here by running
> another layout at a later time but I’m interested to hear others on how
> this should be solved.
>
> From: yishayw@mailto:yishayw@;
> Sent: Sunday, June 3, 2018 1:12 PM
> To: commits@.apachemailto:commits@.apache;
> Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a
> proper fix?
>
> This is an automated email from the ASF dual-hosted git repository.
>
> yishayw pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 37a3a6d  Fixes #258. But is that a proper fix?
> 37a3a6d is described below
>
> commit 37a3a6d5a433d97b654b134f4d354214224172b6
> Author: DESKTOP-RH4S838\Yishay yishayjobs@
> AuthorDate: Sun Jun 3 13:11:31 2018 +0300
>
> Fixes #258. But is that a proper fix?
> ---
>  examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7
> ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> index 8b70a52..f25bfdf 100644
> --- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> +++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> @@ -39,6 +39,11 @@ limitations under the License.
>
>  
>  
>  
>
> @@ -56,7 +61,7 @@ limitations under the License.
>  
>  
>
> -rowHeight="40">
> +rowHeight="40">
>  
>sourceID="applicationModel"
>
> --
> To stop receiving notification emails like this one, please contact
> yishayw@.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira





--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Carlos Rovira]

Hi Yishay,

this seems like a bug to be fixed at the core of the component, or the
layout system.

I was not aware about Layout Challenges page. But for me I'll prefer to
discuss in mailing list, since GitHub pages seems more like a reference
site, more than a discussion place. Said that this weekend I was making
some important changes to jewel layouts, I want to fix some left things and
write about it to let you all know what's all about.

thanks


2018-06-03 12:21 GMT+02:00 Yishay Weiss :

> This could be a good topic to put down here…
>
> https://github.com/apache/royale-asjs/wiki/Layout-Challenges
>
>
> 
> From: Yishay Weiss 
> Sent: Sunday, June 3, 2018 1:18:03 PM
> To: dev@royale.apache.org
> Subject: RE: [royale-asjs] branch develop updated: Fixes #258. But is that
> a proper fix?
>
> I’ve seen several instances where the offsetParent hasn’t been set yet
> when layout is run, which messes things up. I solved this here by running
> another layout at a later time but I’m interested to hear others on how
> this should be solved.
>
> From: yish...@apache.org<mailto:yish...@apache.org>
> Sent: Sunday, June 3, 2018 1:12 PM
> To: comm...@royale.apache.org<mailto:comm...@royale.apache.org>
> Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a
> proper fix?
>
> This is an automated email from the ASF dual-hosted git repository.
>
> yishayw pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 37a3a6d  Fixes #258. But is that a proper fix?
> 37a3a6d is described below
>
> commit 37a3a6d5a433d97b654b134f4d354214224172b6
> Author: DESKTOP-RH4S838\Yishay 
> AuthorDate: Sun Jun 3 13:11:31 2018 +0300
>
> Fixes #258. But is that a proper fix?
> ---
>  examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7
> ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> index 8b70a52..f25bfdf 100644
> --- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> +++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> @@ -39,6 +39,11 @@ limitations under the License.
>
>  
>  
>  
>
> @@ -56,7 +61,7 @@ limitations under the License.
>  
>  
>
> -rowHeight="40">
> +rowHeight="40">
>  
>sourceID="applicationModel"
>
> --
> To stop receiving notification emails like this one, please contact
> yish...@apache.org.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

This could be a good topic to put down here…

https://github.com/apache/royale-asjs/wiki/Layout-Challenges



From: Yishay Weiss 
Sent: Sunday, June 3, 2018 1:18:03 PM
To: dev@royale.apache.org
Subject: RE: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

I’ve seen several instances where the offsetParent hasn’t been set yet when 
layout is run, which messes things up. I solved this here by running another 
layout at a later time but I’m interested to hear others on how this should be 
solved.

From: yish...@apache.org<mailto:yish...@apache.org>
Sent: Sunday, June 3, 2018 1:12 PM
To: comm...@royale.apache.org<mailto:comm...@royale.apache.org>
Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a proper 
fix?

This is an automated email from the ASF dual-hosted git repository.

yishayw pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/royale-asjs.git


The following commit(s) were added to refs/heads/develop by this push:
 new 37a3a6d  Fixes #258. But is that a proper fix?
37a3a6d is described below

commit 37a3a6d5a433d97b654b134f4d354214224172b6
Author: DESKTOP-RH4S838\Yishay 
AuthorDate: Sun Jun 3 13:11:31 2018 +0300

Fixes #258. But is that a proper fix?
---
 examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml 
b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
index 8b70a52..f25bfdf 100644
--- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
+++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
@@ -39,6 +39,11 @@ limitations under the License.

 
 
 

@@ -56,7 +61,7 @@ limitations under the License.
 
 

-   
+   
 
 

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Yishay Weiss]

I’ve seen several instances where the offsetParent hasn’t been set yet when 
layout is run, which messes things up. I solved this here by running another 
layout at a later time but I’m interested to hear others on how this should be 
solved.

From: yish...@apache.org
Sent: Sunday, June 3, 2018 1:12 PM
To: comm...@royale.apache.org
Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a proper 
fix?

This is an automated email from the ASF dual-hosted git repository.

yishayw pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/royale-asjs.git


The following commit(s) were added to refs/heads/develop by this push:
 new 37a3a6d  Fixes #258. But is that a proper fix?
37a3a6d is described below

commit 37a3a6d5a433d97b654b134f4d354214224172b6
Author: DESKTOP-RH4S838\Yishay 
AuthorDate: Sun Jun 3 13:11:31 2018 +0300

Fixes #258. But is that a proper fix?
---
 examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml 
b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
index 8b70a52..f25bfdf 100644
--- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
+++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
@@ -39,6 +39,11 @@ limitations under the License.

 
 
 

@@ -56,7 +61,7 @@ limitations under the License.
 
 

-   
+