Yes. Flexbox solves a lot of problems, and I use the “flex” layouts pretty extensively.
However, I have run into lots of cases which are hard to solve and the old Flex-style layouts would have been helpful. > On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote: > > Lately I had huge exercises with FlexBox mechanism and it is finally > something. I have never seen better working things in HTML than this. If I > wanted to make elements on the right they are really displays on the right. > - Without FlexBox I would be nowhere. > > Maybe it is not the answer for the constrained layout, but it is something. > > Thanks, > Piotr > > 2018-02-07 17:24 GMT+01:00 Gabe Harbs <harbs.li...@gmail.com>: > >> FWIW, I do think we need a “constrained layout” which places *everything* >> absolutely and does not rely on browser layout. If that layout were to be >> used, the bounding box values would be correct. >> >>> On Feb 7, 2018, at 6:00 PM, Peter Ent <p...@adobe.com.INVALID> wrote: >>> >>> I think I agree with Harbs about x,y,width,height just returning the set >>> values if the calculation would be expensive. I wonder what the >>> circumstances are that we actually need to have precise values in >>> calculations. For example, if I wanted to make a circulate layout, how >>> would I go about doing that? >>> >>> In the places I've done layouts without regard to platform I'm just >>> assuming things work. For example, in the DataGridLayout, I need to >>> transfer the column width given on the js:DataGridColumn definition to >>> both the List (column) and the corresponding Button in the ButtonBar. >>> Ideally, the browser takes that (along with display and position styles) >>> and just does the right thing with minimum code on our part (that's not >>> actually what I'm doing, so perhaps I should rethink that one more time). >>> >>> ‹peter >>> >>> On 2/7/18, 8:35 AM, "Gabe Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> The offset values are very expensive. >>>> >>>> They are also not completely accurate. I¹ve found it¹s difficult to get >>>> accurate values where SVG and transforms are in play. >>>> >>>> I would suggest that x,y,widht and height should reflect *set* values >>>> even if they are not always the actual ones. >>>> >>>> For cases where it¹s necessary to get accurate measured x,y,width and >>>> height, I would suggest using ³measured² variations of these values, or >>>> better, a getMeasuredBounds() method. >>>> >>>>> On Feb 7, 2018, at 10:43 AM, Alex Harui <aha...@adobe.com.INVALID> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> In Royale on JS, we are trying to leverage the browser's layout code as >>>>> much as possible. We only run our own layout code in a few places. >>>>> In debugging a few layout issues I discovered that UIBase is not >>>>> reporting >>>>> x and y the way we expect it from Flex/Flash. Browser elements don't >>>>> have >>>>> x and y properties, instead they have offsetLeft and offsetTop. Mainly >>>>> for backward-compatibility with Flex/Flash, Royale has had x and y in >>>>> the >>>>> API since the beginning. I think it is a bug that x and y do not act >>>>> like >>>>> they do in Flex and plan to fix that after this release. Thoughts? >>>>> I'm a >>>>> bit concerned of the expense of calculating x and y because you have to >>>>> check if the offsetParent is your immediate parent and get the >>>>> offsetLeft/offsetTop of the immediate parent, but I think that's what >> it >>>>> would take to fix it. >>>>> >>>>> Similarly (well, sort of), Flex did not support CSS margins, only >>>>> padding. >>>>> The browser reports width (offsetWidth) as factoring in content, >> padding >>>>> and borders, but not margin. I think that's right, and matches Flex. >>>>> However, our custom layout algorithms do not currently factor in >> margins >>>>> since they are not reported in width. I think our custom layout should >>>>> request width and margins and do the math. We should not change width >>>>> to >>>>> include margins. Thoughts? This will make our custom layout code a >> bit >>>>> more expensive as well as it will probably need to call >>>>> getComputedStyles() on all of the children in order to get margins. >>>>> This >>>>> is also something to fix in the next release. >>>>> >>>>> Of course, I could be wrong. Thoughts? >>>>> >>>>> -Alex >>>>> >>>> >>> >> >> > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>*
