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
