royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabe Harbs <harbs.li...@gmail.com>
Subject Re: What is x and y? What is width and height?
Date Wed, 07 Feb 2018 16:24:48 GMT
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 <pent@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.lists@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 <aharui@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
>>> 
>> 
> 


Mime
View raw message