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" <aha...@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" <p...@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" <harbs.li...@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 <p...@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" <coxfrede...@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 <p...@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 >>>>>> >>>> >>> >> >
