royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?
Date Tue, 05 Jun 2018 06:25:01 GMT
Yeah. If you’d need static for some reason, you’d specify that. I think needing static
instead of relative would be pretty rare. Here’s an interesting article.[1]

I think the fact that static is the default in HTML is more of conceptual decision (less opinion
on positioning) than a practical one (static leads to unexpected layout).

Even describing what static does is complicated as opposed to relative which is conceptually
simple.[2]

All in all, relative seems like the right default for Royale apps to have.

My $0.02,
Harbs

[1]https://css-tricks.com/what-if-there-was-no-position-static/ <https://css-tricks.com/what-if-there-was-no-position-static/>
[2]https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document
<https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document>

> On Jun 5, 2018, at 8:23 AM, Alex Harui <aharui@adobe.com.INVALID> wrote:
> 
> What I'm wondering is how you would make it so it was as if that selector wasn't specified
at all.  I guess the default value for position is "static" so the user would specify position:
static?
> 
> -Alex
> 
> On 6/4/18, 10:03 PM, "Harbs" <harbs.lists@gmail.com> wrote:
> 
>    Any other selector should disable that one because that’s about as unspecific as
you can get and the higher level of specificity always wins.
> 
>> On Jun 5, 2018, at 8:00 AM, Alex Harui <aharui@adobe.com.INVALID> wrote:
>> 
>> Ah, ok.  How would a user disable that selector in case it did something undesirable?
>> 
>> -Alex
>> 
>> On 6/4/18, 1:56 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>> 
>>   Sorry I was a bit confused. The selector that works is:
>> 
>>   .Application * {
>>   	position: relative;
>>   }
>> 
>>> On Jun 4, 2018, at 11:32 PM, Harbs <harbs.lists@gmail.com> wrote:
>>> 
>>> Yes. But it cascades down.
>>> 
>>> I manually made this change to the TreeExample project, and it fixed the bug.
>>> 
>>>> On Jun 4, 2018, at 7:22 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
>>>> 
>>>> I'm still not understanding.  Style.position is not inheriting so how would
it cascade down?  Isn't .Application only applied to the <body/>?
>>>> 
>>>> Thanks,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 9:15 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>> 
>>>> I’m suggesting that we change defaults.css
>>>> 
>>>> from:
>>>> Application
>>>> {
>>>> 	padding: 0px;
>>>> 	margin: 0px;
>>>> }
>>>> 
>>>> to:
>>>> Application
>>>> {
>>>> 	padding: 0px;
>>>> 	margin: 0px;
>>>> 	position: relative;
>>>> }
>>>> 
>>>> I believe this will resolve this issue as the default would cascade down
to all sub-elements. The default would be relative, but beads would be free to change that
to whatever they want.
>>>> 
>>>> Of course, that would dictate that UIBase belongs in Basic and not Core…
;-)
>>>> 
>>>> Harbs
>>>> 
>>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui <aharui@adobe.com.INVALID>
wrote:
>>>>> 
>>>>> I’m not sure exactly what change you are proposing, but UIBase used
to set position=relative on all positioners.  We took that away so that the "flex" and other
display/layout styles would not have to deal with the excess clutter and overhead of having
set position on so many elements in the DOM.  Via PAYG, only the elements that need to have
a style.position should have it set.
>>>>> 
>>>>> My 2 cents,
>>>>> -Alex
>>>>> 
>>>>> On 6/4/18, 8:44 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>> 
>>>>> It just occurred to me that the problem is due to the default position
being static.
>>>>> 
>>>>> I just added position: relative; to the .Application css and that resolved
the issue as well.
>>>>> 
>>>>> I wonder if we could completely do away with the offsetParent logic in
UIBase if we make the default position: relative. That would have a major positive impact
on performance.
>>>>> 
>>>>> Thoughts?
>>>>> Harbs
>>>>> 
>>>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui <aharui@adobe.com.INVALID>
wrote:
>>>>>> 
>>>>>> Hi Yishay,
>>>>>> 
>>>>>> IMO, the new fix is better.  And you took the right approach by examining
the code flow in the debugger.  When layout fails for what appears to be a timing issue (in
this case, offsetParent not set), we definitely want to take the time to carefully analyze
why there is a timing issue instead of apply code to work around the current lifecycle.
>>>>>> 
>>>>>> I'm not sure we can recommend a general pattern for layouts.  I think
there is some PAYG involved.  It could be that in some cases the View should be responsible
for setting style.position.  Then the layouts don't have to spend the time verifying style.position.
 In other cases the layouts could be used in places where other potential layouts don't rely
on style.position being a particular value.  I think BasicLayout for Containers is an example.
>>>>>> 
>>>>>> The code you used could be put into a utility function for layouts
to use to guarantee that x,y will work as expected.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Alex
>>>>>> 
>>>>>> On 6/4/18, 8:22 AM, "yishayw" <yishayjobs@hotmail.com> wrote:
>>>>>> 
>>>>>> Looking at it some more it has nothing to do with data binding. I
pushed a
>>>>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes
the
>>>>>> layout itself. Here it's assumed the offsetParent is explicitly set
before
>>>>>> children's x and y are set. Should this be a general pattern?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981&sdata=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D&reserved=0
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message