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 >
