You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Peter Ent <pe...@adobe.com> on 2017/02/28 19:50:51 UTC
[FlexJS] Coordinate Space
Hi,
In an effort to clean up Container and layouts, we need to look at the coordinate system of FlexJS. Since the goal is to have the SWF side mimic the JS side, perhaps we should visit the "coordinate system" of HTML. You'll find an Apache Paste at [1] below. If you could run that and make any changes you'd like and see what you think.
Basically: in Flex 4 and Flash, when you position something at (0,0) and you read its x coordinates back, it is at (0,0). In HTML land, that isn't exactly how it works. There are several things that influence the position of an element: the position style of its parent, the padding of its parent, the margin style of the element and the position style of the element.
If you set a div to have a padding of 10 and an element to have position:relative with left:0 it will appear 10 pixels from the left edge of the div. That's what would expect. However, if you try to read that element's position, you need to use its read-only property, offsetLeft. That value will be 10, not 0.
How would you feel if FlexJS worked the same way?
<js:Container>
<js:style>
<js:SimpleCSSStyles padding="10" />
</js:style>
<js:TextButton id="testButton" x="0" y="0" />
</js:Container>
When you ask for testButton's x or y values it would return 10 due to the padding on its Container parent.
Right now Container has this inner contentArea that tries to make sure testButton is (0,0) but it is a headache to maintain, I think.
[1] https://paste.apache.org/IM1W
Regards,
Peter Ent
Adobe Systems/Apache Flex Project
Re: [FlexJS] Coordinate Space
Posted by yishayw <yi...@hotmail.com>.
This [1] thread talks about the advantages of SWF for JS targeted projects.
[1]
http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Importance-of-SWF-output-td55843.html#a55849
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Coordinate-Space-tp59924p59966.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Coordinate Space
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I think I understand this now.
When you set x, y on a component, you will be setting the left and top
styles on the HTML element. Setting these properties will no longer set
the position style (which will remain unchanged it has been set).
The Container classes will no longer have a default layout. This means you
can use Container and place items in there and style or layout everything
using CSS if you want to go that route. Some of that may not be supported
by the SWF version, however. At least not right away.
The BasicLayout will set the container's position to "relative" if it is
not already set. Then it will go through the children and set their
position styles to "absolute". This way the left and top (as well as
bottom and right) styles will work. Without setting a position of
"absolute" those styles will not locate the components (using a position
of "relative" means that items will be placed in relation to each other,
which you can now do if you do not use the BasicLayout and set position to
"relative" yourself).
NOTE: unlike normal HTML/CSS, FlexJS containers are sized by their
contents: if you do not give a container a size, the layout will determine
the size of that container. In HTML/CSS, you would probably see the
container/div span the entire page by default or have a zero height by
default depending on the placement of the children.
You need to be aware of how margin affects placement. When using absolute
position along with margin, the item will be offset by the margin
value(s). For example, if you set left:10 (or item.x = 10) and add a
margin-left:10, then item's content position will be 20. This will be the
value the x property returns. If you are migrating from Flex 4, just leave
margin settings out.
Also, for BasicLayout (aka, a container with position:relative|absolute
and children with position:absolute), container's padding has no effect.
That is, a container with padding:10 will not change the location of any
of the children placed with BasicLayout. The padding style will affect
other types of layouts.
For the Flexbox layouts, as long as you do not set the left, top (x, y)
style (or property) the items will be placed correctly. Pixel and
percentage dimensions will be honored as well. When you examine the HTML
DOM, you should not see any position or placement styles on the items in a
Flexbox type layout.
Essentially, you should be able to do a lot more of the layout in CSS if
you are targeting HTML/CSS/JS as your main platform. The layout beads are
helpful to do programmatic placement and are how the SWF version will know
what to do.
Finally, there will probably be some new container components. Not sure
what just yet, but we need to have very light ones and others that handle
scrolling and chrome. Stay tuned.
I now need to make these changes, which I will do in a separate branch.
Thank you for your input and suggestions. I think this will solve our
layout issues once complete.
Regards,
Peter
On 3/2/17, 9:37 AM, "Peter Ent" <pe...@adobe.com> wrote:
>We still have to have FlexJS work on both JS and SWF sides with some
>compatibility. We could do this:
>
>x,y sets "native" values. Reading them back on SWF vs JS might yield
>different results if padding, border, and margins are set on the parent
>element. If you don't want your coordinates messed with, then nest your
>containers and apply padding, border, background, etc to the outer
>container. And definitely do not use margins.
>
>If you want to use CSS to position items, use the top, left, bottom, right
>style properties (and margin on the children). On the SWF side, these
>styles will look at the parent's padding and border values and position
>the elements accordingly (it will use x, y). If you intend to read the
>values back, they will not necessarily be what you set since the values
>are determined by the parent's padding and border as well as the child's
>own margin values.
>
>You need to specify layouts inside containers so that the SWF side knows
>what to do. If you don't intend on using the SWF output, you can just set
>the style on the container and let HTML/CSS/JS take care of it. If you
>supply a layout bead, the bead will set the display, positioning, and
>other styles on the container as necessary and may even impose styles on
>the children for the JS side. The SWF side is purely programmatic to mimic
>the JS side and it will be as close as possible but may need to be
>multiple passes.
>
>Scrolling provides more challenges for the SWF side as nested containers
>need to be used with the outer container used to mask the inner which is
>then repositioned to simulate scrolling. When you want scrolling, use
>ScrollableContainer. This class simply sets overflow:auto on the JS side.
>If you do not want or care about the SWF output, then just set the
>overflow style on the container.
>
>‹peter
>
>On 3/1/17, 4:12 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> I think we have confusion over what FlexJS is trying to deliver. If we
>>>are
>>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>>> that, to me, implies SWF is the preferred platform and we need to make
>>> HTML/JS platform conform to it. Thus the coordinate system needs to
>>> reflect that.
>>>
>>> If we are trying to make it possible to use ActionScript and MXML to
>>>build
>>> apps that run on HTML/JS platform primarily with SWF being a good way
>>>to
>>> debug and to also run efficiently, then we need to make clean JS code
>>>and
>>> write code to support/mimic that on SWF.
>>
>>I not sure home many people are going to use the SWF output, but perhaps
>>I¹m missing a use case. I expect currently if people are targeting swf,
>>AIR or mobile they would still use the FlexSDK. Anyone have a different
>>opionion here?
>>
>>The workflow I found to work well as an application developer is
>>basically to ignore the AS side. Reasons being:
>>- The framework code is different on the AS side to the JS and has
>>different features / bugs
>>- Layout is different between plaftforms and it's a lot of work to get an
>>application looking the same in both
>>- AS side is missing support for a number of common style attributes
>>- Issues setting up debugging support in the IDE
>>- Chrome has a decent JS debugger now. You can set breakpoints, look at
>>variables etc etc
>>- Project I¹m working on is targeting JS as final output
>>
>>You still get the benefits of coding in AS and the IDE and compiler pick
>>up a lot of issues for you quickly because of that.
>>
>>> I am not a JavaScript developer so I don't know what JS
>>> folks come to expect and how they work with this coordinate system.
>>>Maybe
>>> most of the UI is static and the apps just use form fields for input
>>>and
>>> effects are set up in CSS and then triggered so programmatic
>>>manipulation
>>> of object position is rare; I don't know.
>>
>>Programmatic manipulation currently is required (IMO) if you want your
>>application to resize nicely / be responsive.
>>
>>If % x, % y, min width / height and max width / height were implemented
>>and/or % height and % width worked differently then it may not be so
>>important.
>>
>>Thanks,
>>Justin
>
Re: [FlexJS] Coordinate Space
Posted by Peter Ent <pe...@adobe.com>.
We still have to have FlexJS work on both JS and SWF sides with some
compatibility. We could do this:
x,y sets "native" values. Reading them back on SWF vs JS might yield
different results if padding, border, and margins are set on the parent
element. If you don't want your coordinates messed with, then nest your
containers and apply padding, border, background, etc to the outer
container. And definitely do not use margins.
If you want to use CSS to position items, use the top, left, bottom, right
style properties (and margin on the children). On the SWF side, these
styles will look at the parent's padding and border values and position
the elements accordingly (it will use x, y). If you intend to read the
values back, they will not necessarily be what you set since the values
are determined by the parent's padding and border as well as the child's
own margin values.
You need to specify layouts inside containers so that the SWF side knows
what to do. If you don't intend on using the SWF output, you can just set
the style on the container and let HTML/CSS/JS take care of it. If you
supply a layout bead, the bead will set the display, positioning, and
other styles on the container as necessary and may even impose styles on
the children for the JS side. The SWF side is purely programmatic to mimic
the JS side and it will be as close as possible but may need to be
multiple passes.
Scrolling provides more challenges for the SWF side as nested containers
need to be used with the outer container used to mask the inner which is
then repositioned to simulate scrolling. When you want scrolling, use
ScrollableContainer. This class simply sets overflow:auto on the JS side.
If you do not want or care about the SWF output, then just set the
overflow style on the container.
‹peter
On 3/1/17, 4:12 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I think we have confusion over what FlexJS is trying to deliver. If we
>>are
>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>> that, to me, implies SWF is the preferred platform and we need to make
>> HTML/JS platform conform to it. Thus the coordinate system needs to
>> reflect that.
>>
>> If we are trying to make it possible to use ActionScript and MXML to
>>build
>> apps that run on HTML/JS platform primarily with SWF being a good way to
>> debug and to also run efficiently, then we need to make clean JS code
>>and
>> write code to support/mimic that on SWF.
>
>I not sure home many people are going to use the SWF output, but perhaps
>I¹m missing a use case. I expect currently if people are targeting swf,
>AIR or mobile they would still use the FlexSDK. Anyone have a different
>opionion here?
>
>The workflow I found to work well as an application developer is
>basically to ignore the AS side. Reasons being:
>- The framework code is different on the AS side to the JS and has
>different features / bugs
>- Layout is different between plaftforms and it's a lot of work to get an
>application looking the same in both
>- AS side is missing support for a number of common style attributes
>- Issues setting up debugging support in the IDE
>- Chrome has a decent JS debugger now. You can set breakpoints, look at
>variables etc etc
>- Project I¹m working on is targeting JS as final output
>
>You still get the benefits of coding in AS and the IDE and compiler pick
>up a lot of issues for you quickly because of that.
>
>> I am not a JavaScript developer so I don't know what JS
>> folks come to expect and how they work with this coordinate system.
>>Maybe
>> most of the UI is static and the apps just use form fields for input and
>> effects are set up in CSS and then triggered so programmatic
>>manipulation
>> of object position is rare; I don't know.
>
>Programmatic manipulation currently is required (IMO) if you want your
>application to resize nicely / be responsive.
>
>If % x, % y, min width / height and max width / height were implemented
>and/or % height and % width worked differently then it may not be so
>important.
>
>Thanks,
>Justin
Re: [FlexJS] Coordinate Space
Posted by ju...@classsoftware.com.
Hi,
Probably better to read the first sentence as " ignore the SWF side”, I still want to code / compile AS (as it pick up more issues) but ignore the SWF output.
> The workflow I found to work well as an application developer is basically to ignore the AS side. Reasons being:
> - The framework code is different on the AS side to the JS and has different features / bugs
> - Layout is different between plaftforms and it's a lot of work to get an application looking the same in both
> - AS side is missing support for a number of common style attributes
> - Issues setting up debugging support in the IDE
> - Chrome has a decent JS debugger now. You can set breakpoints, look at variables etc etc
> - Project I’m working on is targeting JS as final output
>
> You still get the benefits of coding in AS and the IDE and compiler pick up a lot of issues for you quickly because of that.
Thanks,
Justin
Re: [FlexJS] Coordinate Space
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think we have confusion over what FlexJS is trying to deliver. If we are
> trying to make a new Flex that works on both HTML/JS and SWF platforms,
> that, to me, implies SWF is the preferred platform and we need to make
> HTML/JS platform conform to it. Thus the coordinate system needs to
> reflect that.
>
> If we are trying to make it possible to use ActionScript and MXML to build
> apps that run on HTML/JS platform primarily with SWF being a good way to
> debug and to also run efficiently, then we need to make clean JS code and
> write code to support/mimic that on SWF.
I not sure home many people are going to use the SWF output, but perhaps I’m missing a use case. I expect currently if people are targeting swf, AIR or mobile they would still use the FlexSDK. Anyone have a different opionion here?
The workflow I found to work well as an application developer is basically to ignore the AS side. Reasons being:
- The framework code is different on the AS side to the JS and has different features / bugs
- Layout is different between plaftforms and it's a lot of work to get an application looking the same in both
- AS side is missing support for a number of common style attributes
- Issues setting up debugging support in the IDE
- Chrome has a decent JS debugger now. You can set breakpoints, look at variables etc etc
- Project I’m working on is targeting JS as final output
You still get the benefits of coding in AS and the IDE and compiler pick up a lot of issues for you quickly because of that.
> I am not a JavaScript developer so I don't know what JS
> folks come to expect and how they work with this coordinate system. Maybe
> most of the UI is static and the apps just use form fields for input and
> effects are set up in CSS and then triggered so programmatic manipulation
> of object position is rare; I don't know.
Programmatic manipulation currently is required (IMO) if you want your application to resize nicely / be responsive.
If % x, % y, min width / height and max width / height were implemented and/or % height and % width worked differently then it may not be so important.
Thanks,
Justin
Re: [FlexJS] Coordinate Space
Posted by yishayw <yi...@hotmail.com>.
Speaking for myself, my problems haven't been with layouts not being
flex-like but rather with unpredictable behavior. Off the top of my head,
x=0 now sets positioning to absolute, which changes behavior in more than
one way. This is a big side effect, and to me unpredictable side effects are
a pain.
I don't think we should be too worried about keeping the feel of either CSS
or Flex. If the layout has sound internal logic, if it's consistent and well
documented, people will take the time to learn about the rules and use them.
If the user has to think whether x == 10 one line after he s/he set it to
10, I think we lose intuitiveness and usability.
People who want CSS like behavior can just use CSS, not sure why they would
need a layout bead at all. Maybe on the SWF side, but that sounds like an
edge case to me.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Coordinate-Space-tp59924p59964.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Coordinate Space
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If you are creating things from scratch:
> - only use (x,y) in Containers[2] where you do not set the Container's
> padding and you do not set margins on your elements.
I think HContainer and VContainer and % width and % height are likely to be used more often, especialy with layout needing to work on different size screens.
Currently I’m only using Container’s to simulate padding (as it's not supported) or where I want items overlap and then pragmatically set their position based on % width and % height.
Thanks,
Justin
Re: [FlexJS] Coordinate Space
Posted by Peter Ent <pe...@adobe.com>.
How about this…
If you are migrating from Flex 4 to FlexJS, then you:
- use (x,y) to set position
- do not put margins on your elements (margins weren't in Flex anyway)
- Use PaddedContainer[1] whenever you need a Container.
- you can safely apply padding to PaddedContainer and the child elements'
(x,y) will not be adjusted.
If you are creating things from scratch:
- only use (x,y) in Containers[2] where you do not set the Container's
padding and you do not set margins on your elements. Otherwise the value
of (x,y) will be adjusted by the margins and padding (and border thickness
as per HTML).
- instead, set the left, top, right, bottom styles to position elements.
- or use layouts and do not set any positioning.
[1] PaddedContainer will be the current Container, just renamed to reflect
the fact that it can use padding values and will still deliver (x,y)
unchanged unless you put margins on your elements. It does this because it
nests one container inside another with the inner container offset by the
padding values. PaddedContainer will automatically use a scrollable
viewport as its default so there will no extra beads needed. You can
replace the viewport with the non-scrollable one.
[2] Regular Container will be simplified to be a single containing
element. When you use this and give it padding, elements placed into it
will be offset by the padding and their (x,y) will be calculated
accordingly. You should use left, top, right, bottom styles to place these
items or use layouts.
I recommend that Container not allow scrolling and we should instead
introduce ScrollableContainer that will provide scrollbars on the SWF side
and set overflow:auto on the JS side. If you do not care about the SWF
side, then use Container but set overflow:auto in its style. Having
scrollable content on the SWF side involves nested containers.
ScrollableContainer on the SWF side will be nested containers, but padding
will apply to the inner content area. This will make left, top, right,
bottom styles work consistently between SWF and JS while delivering (x,y)
as offset values same as Container.
Regards,
Peter
On 3/1/17, 11:52 AM, "Alex Harui" <ah...@adobe.com> wrote:
>I think there are a couple of things going on:
>
>1) Some folks have asked for an API that reduces migration pain when
>porting existing Flex apps.
>2) We want the thinnest possible overhead over hand-coded HTML/JS/CSS.
>
>These two goals are in opposition because Flex:
>A) didn't support margins
>B) had properties for x,y,width,height instead of styles
>C) used % differently for width and height
>D) you "get what you set". If you set x=0, then on the next line of code
>(x == 0) is true.
>
>Meanwhile, it has been my experience that there are some pain points in
>HTML layouts, like making one object stretch to fill all remaining space
>horizontally or vertically.
>
>It feels like in native HTML/JS you set styles and read properties. There
>is no read/write x and y properties. So one option is to hide the x and y
>properties. But that would probably make migration harder.
>
>So maybe, the first question is:
>What should x and y set, and what should it report back?
>
>Now, IMO, it is totally fine for different component sets to have
>different rules. In the "dual" branch, I've split the more Flex-like
>components (Label, Container, Button) out into the Basic.SWC and HTML.swc
>now contains the thin wrappers of HTMLElements Carlos made which may need
>more work in order to run on SWF, but have HTML element names like A, H1,
>Select, etc.
>
>For these direct HTMLElement-named components, maybe we really should hide
>x and y properties. Then you'd have to set left or leftMargin
>appropriately instead of x. And read back clientX and/or offsetX.
>
>For the Flex-like components in Basic, we could make everything always use
>absolute positioning. And Container would have a more Flex-like
>coordinate space. Don't know if that would help or not.
>
>Thoughts?
>-Alex
>
>On 3/1/17, 7:28 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>I agree with this. Now that these layouts and containers are really
>>getting used in a more practical way we can see what's going on.
>>
>>I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
>>would read x back as 0 but on JS it might read back as 20, depending on
>>padding and border styles.
>>
>>Then .left, .top, .bottom, and .right would be universal and take
>>padding,
>>margin, and border into consideration so that both SWF and JS got the
>>same
>>result.
>>
>>Since most layouts are built in SWF to mimic JS, the SWF side code would
>>use the native .x and .y to position the elements so that each pass would
>>not have to retrieve the parent's padding and border. These SWF layouts
>>should be faster, even if they require multiple passes.
>>
>>Then Container needs to be cleaned up to provide miminum repeated calls
>>to
>>the layout. But we have to keep mind that size determinations might be
>>multiple passes when explicit sizes aren't given.
>>
>>‹peter
>>
>>On 3/1/17, 9:17 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>>I think there should be two separate value sets.
>>>
>>>There should be set values and inferred values.
>>>
>>>Currently FlexJS is relying WAY too much on the browser to get and set
>>>values.
>>>
>>>Case in point: We just profiled our app and using the VerticalLayout,
>>>are
>>>relatively simple layout was taking about 250ms to lay out. Switching
>>>the
>>>VerticalFlexLayout got that time down to about 70ms. However, there are
>>>still lots of DOM calls in ContainerView and 70ms is still a lot. The
>>>browser should only be used to getting and setting values when
>>>*absolutely* necessary.
>>>
>>>I would vote for the default x and y values to be the SET ones and have
>>>another measuredX and measuredY to get the values set by the browser for
>>>cases where that¹s important (which I think is a lot more rare than is
>>>currently assumed).
>>>
>>>My $0.02.
>>>Harbs
>>>
>>>> On Mar 1, 2017, at 3:56 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> I think we have confusion over what FlexJS is trying to deliver. If we
>>>>are
>>>> trying to make a new Flex that works on both HTML/JS and SWF
>>>>platforms,
>>>> that, to me, implies SWF is the preferred platform and we need to make
>>>> HTML/JS platform conform to it. Thus the coordinate system needs to
>>>> reflect that.
>>>>
>>>> If we are trying to make it possible to use ActionScript and MXML to
>>>>build
>>>> apps that run on HTML/JS platform primarily with SWF being a good way
>>>>to
>>>> debug and to also run efficiently, then we need to make clean JS code
>>>>and
>>>> write code to support/mimic that on SWF.
>>>>
>>>> I don't see how it can be both ways. The coordinate systems are very
>>>> different and even on HTML/JS, you can get different values depending
>>>>on
>>>> the box-sizing model being used. Keep in mind that HTML/JS was not
>>>> designed to be an application UI platform which is why tech like
>>>>Flash,
>>>> Canvas, Java, etc. came along (among many other reasons).
>>>>
>>>> This confusion is reflected currently in the code (large portions of
>>>>this
>>>> layout and container were written by yours truly). I believe our
>>>>intention
>>>> is to make HTML/JS the standard and make SWF mimic it as closely as
>>>> possible. However, UI application developers, whether they come from
>>>> Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0
>>>>and
>>>> read x back as 10. I am not a JavaScript developer so I don't know
>>>>what
>>>>JS
>>>> folks come to expect and how they work with this coordinate system.
>>>>Maybe
>>>> most of the UI is static and the apps just use form fields for input
>>>>and
>>>> effects are set up in CSS and then triggered so programmatic
>>>>manipulation
>>>> of object position is rare; I don't know.
>>>>
>>>> But I do know this must be resolved and made consistent before we can
>>>>have
>>>> a first true release. If that means adding nested divs to adjust
>>>> coordinates to make x=0 read back x as zero despite padding and
>>>>margin,
>>>> then we'll do that. Or if it means you need to be aware of padding and
>>>> margin when reading back values, we can do that. We can also introduce
>>>>new
>>>> getters (e.g., absoluteX and absoluteY to be x,y without margin and
>>>> padding).
>>>>
>>>> There are a bunch of options and I'm sorry this wasn't resolved a long
>>>> time ago, but as I said, bridging these platforms is difficult and we
>>>>have
>>>> lots of good stuff written, we just need to shore up the foundation to
>>>> make it tight.
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>> On 3/1/17, 4:07 AM, "Fréderic Cox" <co...@gmail.com> wrote:
>>>>
>>>>> Isn't this what localToGlobal etc.. did for Flex?
>>>>>
>>>>> Personally I would like testButton.x to return 0 in all instances.
>>>>>Unless
>>>>> I
>>>>> want it's actual screen position where I use the helper functions
>>>>>like
>>>>> localToGlobal etc..
>>>>>
>>>>> On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> In an effort to clean up Container and layouts, we need to look at
>>>>>>the
>>>>>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>>>>> mimic
>>>>>> the JS side, perhaps we should visit the "coordinate system" of
>>>>>>HTML.
>>>>>> You'll find an Apache Paste at [1] below. If you could run that and
>>>>>>make
>>>>>> any changes you'd like and see what you think.
>>>>>>
>>>>>> Basically: in Flex 4 and Flash, when you position something at (0,0)
>>>>>>and
>>>>>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>>>>> isn't
>>>>>> exactly how it works. There are several things that influence the
>>>>>> position
>>>>>> of an element: the position style of its parent, the padding of its
>>>>>> parent,
>>>>>> the margin style of the element and the position style of the
>>>>>>element.
>>>>>>
>>>>>> If you set a div to have a padding of 10 and an element to have
>>>>>> position:relative with left:0 it will appear 10 pixels from the left
>>>>>> edge
>>>>>> of the div. That's what would expect. However, if you try to read
>>>>>>that
>>>>>> element's position, you need to use its read-only property,
>>>>>>offsetLeft.
>>>>>> That value will be 10, not 0.
>>>>>>
>>>>>> How would you feel if FlexJS worked the same way?
>>>>>>
>>>>>> <js:Container>
>>>>>> <js:style>
>>>>>> <js:SimpleCSSStyles padding="10" />
>>>>>> </js:style>
>>>>>> <js:TextButton id="testButton" x="0" y="0" />
>>>>>> </js:Container>
>>>>>>
>>>>>> When you ask for testButton's x or y values it would return 10 due
>>>>>>to
>>>>>> the
>>>>>> padding on its Container parent.
>>>>>>
>>>>>> Right now Container has this inner contentArea that tries to make
>>>>>>sure
>>>>>> testButton is (0,0) but it is a headache to maintain, I think.
>>>>>>
>>>>>> [1] https://paste.apache.org/IM1W
>>>>>>
>>>>>> Regards,
>>>>>> Peter Ent
>>>>>> Adobe Systems/Apache Flex Project
>>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Coordinate Space
Posted by Alex Harui <ah...@adobe.com>.
I think there are a couple of things going on:
1) Some folks have asked for an API that reduces migration pain when
porting existing Flex apps.
2) We want the thinnest possible overhead over hand-coded HTML/JS/CSS.
These two goals are in opposition because Flex:
A) didn't support margins
B) had properties for x,y,width,height instead of styles
C) used % differently for width and height
D) you "get what you set". If you set x=0, then on the next line of code
(x == 0) is true.
Meanwhile, it has been my experience that there are some pain points in
HTML layouts, like making one object stretch to fill all remaining space
horizontally or vertically.
It feels like in native HTML/JS you set styles and read properties. There
is no read/write x and y properties. So one option is to hide the x and y
properties. But that would probably make migration harder.
So maybe, the first question is:
What should x and y set, and what should it report back?
Now, IMO, it is totally fine for different component sets to have
different rules. In the "dual" branch, I've split the more Flex-like
components (Label, Container, Button) out into the Basic.SWC and HTML.swc
now contains the thin wrappers of HTMLElements Carlos made which may need
more work in order to run on SWF, but have HTML element names like A, H1,
Select, etc.
For these direct HTMLElement-named components, maybe we really should hide
x and y properties. Then you'd have to set left or leftMargin
appropriately instead of x. And read back clientX and/or offsetX.
For the Flex-like components in Basic, we could make everything always use
absolute positioning. And Container would have a more Flex-like
coordinate space. Don't know if that would help or not.
Thoughts?
-Alex
On 3/1/17, 7:28 AM, "Peter Ent" <pe...@adobe.com> wrote:
>I agree with this. Now that these layouts and containers are really
>getting used in a more practical way we can see what's going on.
>
>I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
>would read x back as 0 but on JS it might read back as 20, depending on
>padding and border styles.
>
>Then .left, .top, .bottom, and .right would be universal and take padding,
>margin, and border into consideration so that both SWF and JS got the same
>result.
>
>Since most layouts are built in SWF to mimic JS, the SWF side code would
>use the native .x and .y to position the elements so that each pass would
>not have to retrieve the parent's padding and border. These SWF layouts
>should be faster, even if they require multiple passes.
>
>Then Container needs to be cleaned up to provide miminum repeated calls to
>the layout. But we have to keep mind that size determinations might be
>multiple passes when explicit sizes aren't given.
>
>‹peter
>
>On 3/1/17, 9:17 AM, "Harbs" <ha...@gmail.com> wrote:
>
>>I think there should be two separate value sets.
>>
>>There should be set values and inferred values.
>>
>>Currently FlexJS is relying WAY too much on the browser to get and set
>>values.
>>
>>Case in point: We just profiled our app and using the VerticalLayout, are
>>relatively simple layout was taking about 250ms to lay out. Switching the
>>VerticalFlexLayout got that time down to about 70ms. However, there are
>>still lots of DOM calls in ContainerView and 70ms is still a lot. The
>>browser should only be used to getting and setting values when
>>*absolutely* necessary.
>>
>>I would vote for the default x and y values to be the SET ones and have
>>another measuredX and measuredY to get the values set by the browser for
>>cases where that¹s important (which I think is a lot more rare than is
>>currently assumed).
>>
>>My $0.02.
>>Harbs
>>
>>> On Mar 1, 2017, at 3:56 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> I think we have confusion over what FlexJS is trying to deliver. If we
>>>are
>>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>>> that, to me, implies SWF is the preferred platform and we need to make
>>> HTML/JS platform conform to it. Thus the coordinate system needs to
>>> reflect that.
>>>
>>> If we are trying to make it possible to use ActionScript and MXML to
>>>build
>>> apps that run on HTML/JS platform primarily with SWF being a good way
>>>to
>>> debug and to also run efficiently, then we need to make clean JS code
>>>and
>>> write code to support/mimic that on SWF.
>>>
>>> I don't see how it can be both ways. The coordinate systems are very
>>> different and even on HTML/JS, you can get different values depending
>>>on
>>> the box-sizing model being used. Keep in mind that HTML/JS was not
>>> designed to be an application UI platform which is why tech like Flash,
>>> Canvas, Java, etc. came along (among many other reasons).
>>>
>>> This confusion is reflected currently in the code (large portions of
>>>this
>>> layout and container were written by yours truly). I believe our
>>>intention
>>> is to make HTML/JS the standard and make SWF mimic it as closely as
>>> possible. However, UI application developers, whether they come from
>>> Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0
>>>and
>>> read x back as 10. I am not a JavaScript developer so I don't know what
>>>JS
>>> folks come to expect and how they work with this coordinate system.
>>>Maybe
>>> most of the UI is static and the apps just use form fields for input
>>>and
>>> effects are set up in CSS and then triggered so programmatic
>>>manipulation
>>> of object position is rare; I don't know.
>>>
>>> But I do know this must be resolved and made consistent before we can
>>>have
>>> a first true release. If that means adding nested divs to adjust
>>> coordinates to make x=0 read back x as zero despite padding and margin,
>>> then we'll do that. Or if it means you need to be aware of padding and
>>> margin when reading back values, we can do that. We can also introduce
>>>new
>>> getters (e.g., absoluteX and absoluteY to be x,y without margin and
>>> padding).
>>>
>>> There are a bunch of options and I'm sorry this wasn't resolved a long
>>> time ago, but as I said, bridging these platforms is difficult and we
>>>have
>>> lots of good stuff written, we just need to shore up the foundation to
>>> make it tight.
>>>
>>> Regards,
>>> Peter
>>>
>>> On 3/1/17, 4:07 AM, "Fréderic Cox" <co...@gmail.com> wrote:
>>>
>>>> Isn't this what localToGlobal etc.. did for Flex?
>>>>
>>>> Personally I would like testButton.x to return 0 in all instances.
>>>>Unless
>>>> I
>>>> want it's actual screen position where I use the helper functions like
>>>> localToGlobal etc..
>>>>
>>>> On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In an effort to clean up Container and layouts, we need to look at
>>>>>the
>>>>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>>>> mimic
>>>>> the JS side, perhaps we should visit the "coordinate system" of HTML.
>>>>> You'll find an Apache Paste at [1] below. If you could run that and
>>>>>make
>>>>> any changes you'd like and see what you think.
>>>>>
>>>>> Basically: in Flex 4 and Flash, when you position something at (0,0)
>>>>>and
>>>>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>>>> isn't
>>>>> exactly how it works. There are several things that influence the
>>>>> position
>>>>> of an element: the position style of its parent, the padding of its
>>>>> parent,
>>>>> the margin style of the element and the position style of the
>>>>>element.
>>>>>
>>>>> If you set a div to have a padding of 10 and an element to have
>>>>> position:relative with left:0 it will appear 10 pixels from the left
>>>>> edge
>>>>> of the div. That's what would expect. However, if you try to read
>>>>>that
>>>>> element's position, you need to use its read-only property,
>>>>>offsetLeft.
>>>>> That value will be 10, not 0.
>>>>>
>>>>> How would you feel if FlexJS worked the same way?
>>>>>
>>>>> <js:Container>
>>>>> <js:style>
>>>>> <js:SimpleCSSStyles padding="10" />
>>>>> </js:style>
>>>>> <js:TextButton id="testButton" x="0" y="0" />
>>>>> </js:Container>
>>>>>
>>>>> When you ask for testButton's x or y values it would return 10 due to
>>>>> the
>>>>> padding on its Container parent.
>>>>>
>>>>> Right now Container has this inner contentArea that tries to make
>>>>>sure
>>>>> testButton is (0,0) but it is a headache to maintain, I think.
>>>>>
>>>>> [1] https://paste.apache.org/IM1W
>>>>>
>>>>> Regards,
>>>>> Peter Ent
>>>>> Adobe Systems/Apache Flex Project
>>>>>
>>>
>>
>
Re: [FlexJS] Coordinate Space
Posted by Peter Ent <pe...@adobe.com>.
I agree with this. Now that these layouts and containers are really
getting used in a more practical way we can see what's going on.
I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
would read x back as 0 but on JS it might read back as 20, depending on
padding and border styles.
Then .left, .top, .bottom, and .right would be universal and take padding,
margin, and border into consideration so that both SWF and JS got the same
result.
Since most layouts are built in SWF to mimic JS, the SWF side code would
use the native .x and .y to position the elements so that each pass would
not have to retrieve the parent's padding and border. These SWF layouts
should be faster, even if they require multiple passes.
Then Container needs to be cleaned up to provide miminum repeated calls to
the layout. But we have to keep mind that size determinations might be
multiple passes when explicit sizes aren't given.
‹peter
On 3/1/17, 9:17 AM, "Harbs" <ha...@gmail.com> wrote:
>I think there should be two separate value sets.
>
>There should be set values and inferred values.
>
>Currently FlexJS is relying WAY too much on the browser to get and set
>values.
>
>Case in point: We just profiled our app and using the VerticalLayout, are
>relatively simple layout was taking about 250ms to lay out. Switching the
>VerticalFlexLayout got that time down to about 70ms. However, there are
>still lots of DOM calls in ContainerView and 70ms is still a lot. The
>browser should only be used to getting and setting values when
>*absolutely* necessary.
>
>I would vote for the default x and y values to be the SET ones and have
>another measuredX and measuredY to get the values set by the browser for
>cases where that¹s important (which I think is a lot more rare than is
>currently assumed).
>
>My $0.02.
>Harbs
>
>> On Mar 1, 2017, at 3:56 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> I think we have confusion over what FlexJS is trying to deliver. If we
>>are
>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>> that, to me, implies SWF is the preferred platform and we need to make
>> HTML/JS platform conform to it. Thus the coordinate system needs to
>> reflect that.
>>
>> If we are trying to make it possible to use ActionScript and MXML to
>>build
>> apps that run on HTML/JS platform primarily with SWF being a good way to
>> debug and to also run efficiently, then we need to make clean JS code
>>and
>> write code to support/mimic that on SWF.
>>
>> I don't see how it can be both ways. The coordinate systems are very
>> different and even on HTML/JS, you can get different values depending on
>> the box-sizing model being used. Keep in mind that HTML/JS was not
>> designed to be an application UI platform which is why tech like Flash,
>> Canvas, Java, etc. came along (among many other reasons).
>>
>> This confusion is reflected currently in the code (large portions of
>>this
>> layout and container were written by yours truly). I believe our
>>intention
>> is to make HTML/JS the standard and make SWF mimic it as closely as
>> possible. However, UI application developers, whether they come from
>> Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0
>>and
>> read x back as 10. I am not a JavaScript developer so I don't know what
>>JS
>> folks come to expect and how they work with this coordinate system.
>>Maybe
>> most of the UI is static and the apps just use form fields for input and
>> effects are set up in CSS and then triggered so programmatic
>>manipulation
>> of object position is rare; I don't know.
>>
>> But I do know this must be resolved and made consistent before we can
>>have
>> a first true release. If that means adding nested divs to adjust
>> coordinates to make x=0 read back x as zero despite padding and margin,
>> then we'll do that. Or if it means you need to be aware of padding and
>> margin when reading back values, we can do that. We can also introduce
>>new
>> getters (e.g., absoluteX and absoluteY to be x,y without margin and
>> padding).
>>
>> There are a bunch of options and I'm sorry this wasn't resolved a long
>> time ago, but as I said, bridging these platforms is difficult and we
>>have
>> lots of good stuff written, we just need to shore up the foundation to
>> make it tight.
>>
>> Regards,
>> Peter
>>
>> On 3/1/17, 4:07 AM, "Fréderic Cox" <co...@gmail.com> wrote:
>>
>>> Isn't this what localToGlobal etc.. did for Flex?
>>>
>>> Personally I would like testButton.x to return 0 in all instances.
>>>Unless
>>> I
>>> want it's actual screen position where I use the helper functions like
>>> localToGlobal etc..
>>>
>>> On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> In an effort to clean up Container and layouts, we need to look at the
>>>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>>> mimic
>>>> the JS side, perhaps we should visit the "coordinate system" of HTML.
>>>> You'll find an Apache Paste at [1] below. If you could run that and
>>>>make
>>>> any changes you'd like and see what you think.
>>>>
>>>> Basically: in Flex 4 and Flash, when you position something at (0,0)
>>>>and
>>>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>>> isn't
>>>> exactly how it works. There are several things that influence the
>>>> position
>>>> of an element: the position style of its parent, the padding of its
>>>> parent,
>>>> the margin style of the element and the position style of the element.
>>>>
>>>> If you set a div to have a padding of 10 and an element to have
>>>> position:relative with left:0 it will appear 10 pixels from the left
>>>> edge
>>>> of the div. That's what would expect. However, if you try to read that
>>>> element's position, you need to use its read-only property,
>>>>offsetLeft.
>>>> That value will be 10, not 0.
>>>>
>>>> How would you feel if FlexJS worked the same way?
>>>>
>>>> <js:Container>
>>>> <js:style>
>>>> <js:SimpleCSSStyles padding="10" />
>>>> </js:style>
>>>> <js:TextButton id="testButton" x="0" y="0" />
>>>> </js:Container>
>>>>
>>>> When you ask for testButton's x or y values it would return 10 due to
>>>> the
>>>> padding on its Container parent.
>>>>
>>>> Right now Container has this inner contentArea that tries to make sure
>>>> testButton is (0,0) but it is a headache to maintain, I think.
>>>>
>>>> [1] https://paste.apache.org/IM1W
>>>>
>>>> Regards,
>>>> Peter Ent
>>>> Adobe Systems/Apache Flex Project
>>>>
>>
>
Re: [FlexJS] Coordinate Space
Posted by Harbs <ha...@gmail.com>.
I think there should be two separate value sets.
There should be set values and inferred values.
Currently FlexJS is relying WAY too much on the browser to get and set values.
Case in point: We just profiled our app and using the VerticalLayout, are relatively simple layout was taking about 250ms to lay out. Switching the VerticalFlexLayout got that time down to about 70ms. However, there are still lots of DOM calls in ContainerView and 70ms is still a lot. The browser should only be used to getting and setting values when *absolutely* necessary.
I would vote for the default x and y values to be the SET ones and have another measuredX and measuredY to get the values set by the browser for cases where that’s important (which I think is a lot more rare than is currently assumed).
My $0.02.
Harbs
> On Mar 1, 2017, at 3:56 PM, Peter Ent <pe...@adobe.com> wrote:
>
> I think we have confusion over what FlexJS is trying to deliver. If we are
> trying to make a new Flex that works on both HTML/JS and SWF platforms,
> that, to me, implies SWF is the preferred platform and we need to make
> HTML/JS platform conform to it. Thus the coordinate system needs to
> reflect that.
>
> If we are trying to make it possible to use ActionScript and MXML to build
> apps that run on HTML/JS platform primarily with SWF being a good way to
> debug and to also run efficiently, then we need to make clean JS code and
> write code to support/mimic that on SWF.
>
> I don't see how it can be both ways. The coordinate systems are very
> different and even on HTML/JS, you can get different values depending on
> the box-sizing model being used. Keep in mind that HTML/JS was not
> designed to be an application UI platform which is why tech like Flash,
> Canvas, Java, etc. came along (among many other reasons).
>
> This confusion is reflected currently in the code (large portions of this
> layout and container were written by yours truly). I believe our intention
> is to make HTML/JS the standard and make SWF mimic it as closely as
> possible. However, UI application developers, whether they come from
> Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0 and
> read x back as 10. I am not a JavaScript developer so I don't know what JS
> folks come to expect and how they work with this coordinate system. Maybe
> most of the UI is static and the apps just use form fields for input and
> effects are set up in CSS and then triggered so programmatic manipulation
> of object position is rare; I don't know.
>
> But I do know this must be resolved and made consistent before we can have
> a first true release. If that means adding nested divs to adjust
> coordinates to make x=0 read back x as zero despite padding and margin,
> then we'll do that. Or if it means you need to be aware of padding and
> margin when reading back values, we can do that. We can also introduce new
> getters (e.g., absoluteX and absoluteY to be x,y without margin and
> padding).
>
> There are a bunch of options and I'm sorry this wasn't resolved a long
> time ago, but as I said, bridging these platforms is difficult and we have
> lots of good stuff written, we just need to shore up the foundation to
> make it tight.
>
> Regards,
> Peter
>
> On 3/1/17, 4:07 AM, "Fréderic Cox" <co...@gmail.com> wrote:
>
>> Isn't this what localToGlobal etc.. did for Flex?
>>
>> Personally I would like testButton.x to return 0 in all instances. Unless
>> I
>> want it's actual screen position where I use the helper functions like
>> localToGlobal etc..
>>
>> On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>>> Hi,
>>>
>>> In an effort to clean up Container and layouts, we need to look at the
>>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>> mimic
>>> the JS side, perhaps we should visit the "coordinate system" of HTML.
>>> You'll find an Apache Paste at [1] below. If you could run that and make
>>> any changes you'd like and see what you think.
>>>
>>> Basically: in Flex 4 and Flash, when you position something at (0,0) and
>>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>> isn't
>>> exactly how it works. There are several things that influence the
>>> position
>>> of an element: the position style of its parent, the padding of its
>>> parent,
>>> the margin style of the element and the position style of the element.
>>>
>>> If you set a div to have a padding of 10 and an element to have
>>> position:relative with left:0 it will appear 10 pixels from the left
>>> edge
>>> of the div. That's what would expect. However, if you try to read that
>>> element's position, you need to use its read-only property, offsetLeft.
>>> That value will be 10, not 0.
>>>
>>> How would you feel if FlexJS worked the same way?
>>>
>>> <js:Container>
>>> <js:style>
>>> <js:SimpleCSSStyles padding="10" />
>>> </js:style>
>>> <js:TextButton id="testButton" x="0" y="0" />
>>> </js:Container>
>>>
>>> When you ask for testButton's x or y values it would return 10 due to
>>> the
>>> padding on its Container parent.
>>>
>>> Right now Container has this inner contentArea that tries to make sure
>>> testButton is (0,0) but it is a headache to maintain, I think.
>>>
>>> [1] https://paste.apache.org/IM1W
>>>
>>> Regards,
>>> Peter Ent
>>> Adobe Systems/Apache Flex Project
>>>
>
Re: [FlexJS] Coordinate Space
Posted by Peter Ent <pe...@adobe.com>.
I think we have confusion over what FlexJS is trying to deliver. If we are
trying to make a new Flex that works on both HTML/JS and SWF platforms,
that, to me, implies SWF is the preferred platform and we need to make
HTML/JS platform conform to it. Thus the coordinate system needs to
reflect that.
If we are trying to make it possible to use ActionScript and MXML to build
apps that run on HTML/JS platform primarily with SWF being a good way to
debug and to also run efficiently, then we need to make clean JS code and
write code to support/mimic that on SWF.
I don't see how it can be both ways. The coordinate systems are very
different and even on HTML/JS, you can get different values depending on
the box-sizing model being used. Keep in mind that HTML/JS was not
designed to be an application UI platform which is why tech like Flash,
Canvas, Java, etc. came along (among many other reasons).
This confusion is reflected currently in the code (large portions of this
layout and container were written by yours truly). I believe our intention
is to make HTML/JS the standard and make SWF mimic it as closely as
possible. However, UI application developers, whether they come from
Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0 and
read x back as 10. I am not a JavaScript developer so I don't know what JS
folks come to expect and how they work with this coordinate system. Maybe
most of the UI is static and the apps just use form fields for input and
effects are set up in CSS and then triggered so programmatic manipulation
of object position is rare; I don't know.
But I do know this must be resolved and made consistent before we can have
a first true release. If that means adding nested divs to adjust
coordinates to make x=0 read back x as zero despite padding and margin,
then we'll do that. Or if it means you need to be aware of padding and
margin when reading back values, we can do that. We can also introduce new
getters (e.g., absoluteX and absoluteY to be x,y without margin and
padding).
There are a bunch of options and I'm sorry this wasn't resolved a long
time ago, but as I said, bridging these platforms is difficult and we have
lots of good stuff written, we just need to shore up the foundation to
make it tight.
Regards,
Peter
On 3/1/17, 4:07 AM, "Fréderic Cox" <co...@gmail.com> wrote:
>Isn't this what localToGlobal etc.. did for Flex?
>
>Personally I would like testButton.x to return 0 in all instances. Unless
>I
>want it's actual screen position where I use the helper functions like
>localToGlobal etc..
>
>On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
>
>> Hi,
>>
>> In an effort to clean up Container and layouts, we need to look at the
>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>mimic
>> the JS side, perhaps we should visit the "coordinate system" of HTML.
>> You'll find an Apache Paste at [1] below. If you could run that and make
>> any changes you'd like and see what you think.
>>
>> Basically: in Flex 4 and Flash, when you position something at (0,0) and
>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>isn't
>> exactly how it works. There are several things that influence the
>>position
>> of an element: the position style of its parent, the padding of its
>>parent,
>> the margin style of the element and the position style of the element.
>>
>> If you set a div to have a padding of 10 and an element to have
>> position:relative with left:0 it will appear 10 pixels from the left
>>edge
>> of the div. That's what would expect. However, if you try to read that
>> element's position, you need to use its read-only property, offsetLeft.
>> That value will be 10, not 0.
>>
>> How would you feel if FlexJS worked the same way?
>>
>> <js:Container>
>> <js:style>
>> <js:SimpleCSSStyles padding="10" />
>> </js:style>
>> <js:TextButton id="testButton" x="0" y="0" />
>> </js:Container>
>>
>> When you ask for testButton's x or y values it would return 10 due to
>>the
>> padding on its Container parent.
>>
>> Right now Container has this inner contentArea that tries to make sure
>> testButton is (0,0) but it is a headache to maintain, I think.
>>
>> [1] https://paste.apache.org/IM1W
>>
>> Regards,
>> Peter Ent
>> Adobe Systems/Apache Flex Project
>>
Re: [FlexJS] Coordinate Space
Posted by Fréderic Cox <co...@gmail.com>.
Isn't this what localToGlobal etc.. did for Flex?
Personally I would like testButton.x to return 0 in all instances. Unless I
want it's actual screen position where I use the helper functions like
localToGlobal etc..
On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <pe...@adobe.com> wrote:
> Hi,
>
> In an effort to clean up Container and layouts, we need to look at the
> coordinate system of FlexJS. Since the goal is to have the SWF side mimic
> the JS side, perhaps we should visit the "coordinate system" of HTML.
> You'll find an Apache Paste at [1] below. If you could run that and make
> any changes you'd like and see what you think.
>
> Basically: in Flex 4 and Flash, when you position something at (0,0) and
> you read its x coordinates back, it is at (0,0). In HTML land, that isn't
> exactly how it works. There are several things that influence the position
> of an element: the position style of its parent, the padding of its parent,
> the margin style of the element and the position style of the element.
>
> If you set a div to have a padding of 10 and an element to have
> position:relative with left:0 it will appear 10 pixels from the left edge
> of the div. That's what would expect. However, if you try to read that
> element's position, you need to use its read-only property, offsetLeft.
> That value will be 10, not 0.
>
> How would you feel if FlexJS worked the same way?
>
> <js:Container>
> <js:style>
> <js:SimpleCSSStyles padding="10" />
> </js:style>
> <js:TextButton id="testButton" x="0" y="0" />
> </js:Container>
>
> When you ask for testButton's x or y values it would return 10 due to the
> padding on its Container parent.
>
> Right now Container has this inner contentArea that tries to make sure
> testButton is (0,0) but it is a headache to maintain, I think.
>
> [1] https://paste.apache.org/IM1W
>
> Regards,
> Peter Ent
> Adobe Systems/Apache Flex Project
>