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