Can you post into the separate thread if it's even possible any of those case ?
2018-02-07 17:36 GMT+01:00 Gabe Harbs <[email protected]>: > 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 <[email protected]> > 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 <[email protected]>: > > > >> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > >>>>> 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>* > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
