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