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 >>>> >> >
