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
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:
>
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
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
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
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
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
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
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
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
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
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
> 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
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
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,
>
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,
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
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
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…
>
>>
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:
>
>
>
>
>
>
>
>
>
> 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
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
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()" >
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
> 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
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
> 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
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;
> 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 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
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
> 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
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
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
> 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
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
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,
> 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
e-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
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
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
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
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:
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
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
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
> ... 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
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
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:
; 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
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
t; 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:relat
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
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
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
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
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
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
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
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
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
]
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
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
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,
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):
>
>>
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,
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;
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.
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
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:
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
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
nt: 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 solve
ki/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 insta
ish...@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 pus
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 br
76 matches
Mail list logo
