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" <p...@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" <jus...@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 >
