You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Piotr Zarzycki <pi...@gmail.com> on 2018/02/07 16:34:45 UTC
Re: What is x and y? What is width and height?
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 <ha...@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 <pe...@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" <ha...@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 <ah...@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>*
Re: What is x and y? What is width and height?
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hmm. Maybe we need to understand the circumstances. It makes no sense to
me to have x,y return useless values just because it is easy or fast to
do. The main point is that in the HTML/JS/CSS world there is no x,y
values so we can make them do anything we want, but do we want it to work
like Flex/Flash? I think so.
Clearly, most of our examples and applications don't care about x,y
otherwise we would have hit this earlier. Or maybe we've worked around it
in the few places we've hit it. Fixing it is unlikely to cause apps to
have performance issues. Basically, there are going to be scenarios where
we don't want the browser to run its normal layout. One example is in
ASDoc where you have a 3-pane UI with scrollbars. There is no way to make
that work with display:flex in some browsers. But the scenario I just ran
into was floating a popup or dropdown underneath some UI widget. Right
now, checking the widget's x,y will not return the right value. I think
it should, no matter how long it takes to compute it. Another scenario I
expect us to hit more often is when we run effects. That also tends to
float UI widgets and position them.
Under PAYG, we might have default code that expects that nothing is
transformed and even slower code if transforms are in play.
The issue about width is different from the issue about x,y. Do we want
width to factor in margins or not? And, independent of that, do we accept
that we must call getComputedStyles() if width hasn't been otherwise set
in order to return the right value?
Thoughts?
-Alex
On 2/7/18, 8:40 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>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 <ha...@gmail.com>:
>
>> 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 <pi...@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 <ha...@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 <pe...@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" <ha...@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 <ah...@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f41564
>>4cf8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361
>>84438193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&rese
>>rved=0
>> >
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f41564
>>4cf8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361
>>84438193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&rese
>>rved=0>*
>>
>>
>
>
>--
>
>Piotr Zarzycki
>
>Patreon:
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f415644c
>f8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361844
>38193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&reserved
>=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C20e5b1f415644c
>f8acfd08d56e498736%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365361844
>38193485&sdata=UR%2Bva%2Fr6xNyIUTi5ZIALzU8zLTkbDh59lYoX84hKDF0%3D&reserved
>=0>*
Re: What is x and y? What is width and height?
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ha...@gmail.com>:
> 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 <pi...@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 <ha...@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 <pe...@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" <ha...@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 <ah...@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>*
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: What is x and y? What is width and height?
Posted by Gabe Harbs <ha...@gmail.com>.
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 <pi...@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 <ha...@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 <pe...@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" <ha...@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 <ah...@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>*