date:20180604

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"  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  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"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  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  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  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  
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"  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  
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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

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  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"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  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  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how would 
>>> it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  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  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
>

RE: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

2018-06-04 Thread Yishay Weiss

This looks ok to me. As I understand it [1] the only difference between 
position: static (which is the default) and position: relative is that they 
don’t obey left, top, bottom, right rules. Since Royale won’t be injecting 
unintended offset values, the default behavior shouldn’t change.

[1] 
https://stackoverflow.com/questions/5011211/difference-between-static-and-relative-positioning

From: Harbs 
Sent: Monday, June 4, 2018 11:55:52 PM
To: dev@royale.apache.org
Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
proper fix?

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  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  wrote:
>>
>> I'm still not understanding.  Style.position is not inheriting so how would 
>> it cascade down?  Isn't .Application only applied to the ?
>>
>> Thanks,
>> -Alex
>>
>> On 6/4/18, 9:15 AM, "Harbs"  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  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0

>>>
>>>
>>>
>>
>>
>>
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

Ah, ok.  How would a user disable that selector in case it did something 
undesirable?

-Alex

On 6/4/18, 1:56 PM, "Harbs"  wrote:

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  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  wrote:
>> 
>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 9:15 AM, "Harbs"  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  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"  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  
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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0

>>> 
>>> 
>>> 
>> 
>> 
>> 
>

Re: [royale-asjs] branch develop updated: Removed unselectable selector

I see.  There probably isn't one right way, so some beads might apply styles in 
other ways.  I was thinking it might be more discoverable for a version of 
DisabledBeads to also use Type Selectors.  Otherwise, debugging collisions in 
the use of, say, opacity, by more than one bead will be a pain to debug.

My 2 cents,
-Alex

On 6/4/18, 1:31 PM, "Harbs"  wrote:

The closest example that we have is probably DisabledBead and 
DisabledAlphaBead. The DisabledAlphaBead applies styling (i.e. an alpha) when 
the DisabledBead disables a component.

I was suggesting that there could be a UnselectableAppearance bead which 
gets applied together with the UnselectableBead and could apply CSS properties. 
That would free the user from having to know which selectors are used.

Harbs

> On Jun 4, 2018, at 7:24 PM, Alex Harui  wrote:
> 
> I think it is too early Monday for me.  I don't understand what you mean 
by "styling could also be a bead".  How would folks discover the selector?
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 9:16 AM, "Harbs"  wrote:
> 
>Fair enough.
> 
>Of course the styling could also be a bead…
> 
>> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
>> 
>> IMO, it is easier for folks to know that there is a selector to override 
or add styles to if it is in one of our .css files instead of buried in code.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 9:11 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
>> 
>>> I don't know why someone would want to override unselectable styles, 
but the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.
>> 
>>   Ah. You mean add additional styles. There’s no reason they couldn’t 
add an additional .unselectable selector with styling elsewhere in the CSS. I 
could go either way on this. If folks feel strongly it should be a “proper” 
selector, I’ll do that.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>>> 
>>> Feel free to change the name of the bead so that the Type Selector name 
looks "better".  I think we agreed to drop the "Bead" portion of names going 
forward.
>>> 
>>> If you are absolutely sure nobody will ever need to override what is in 
that selector, then I'm fine with injecting it with code and using the new 
utility function you created, but otherwise, I would hope we try to write the 
framework without injecting styles with code.  Having overrideable selectors 
should be the recommended practice for a framework.  We want everything to be 
override-able.
>>> 
>>> I don't know why someone would want to override unselectable styles, 
but the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:48 AM, "Harbs" mailto:harbs.li...@gmail.com> >> wrote:
>>> 
>>>  That would probably work. I’m not totally happy with that selector 
name.
>>> 
>>>  I can switch the implementation if you think that’s better. I’m not 
sure why a user would override an “unelectable” style though.
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 6:45 PM, Alex Harui mailto:aha...@adobe.com.INVALID>> wrote:
 
 Hi Harbs,
 
 My suggestion for adding the selector is to make the selector look 
like a Type/Element Selector with the name "UnselectableElementBead".  If you 
do that, then wouldn't that selector be dropped out if nobody is using 
UnselectableElementBead?
 
 I would hope we could find a solution that doesn't result in code 
injecting styles as that sort of screws up users overriding those styles.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 1:14 AM, "Harbs" mailto:harbs.li...@gmail.com> >   On Jun 4, 2018, at 10:24 AM, Carlos Rovira mailto:carlosrov...@apache.org> >> wrote:
> 
> Hi,
>

Re: Incorrect descendent CSS output

Thanks.

I just observed a new problem. I have not pulled in your changes, so I don’t 
know if it’s fixed, but it used to work correctly.

Much of the following css is now being stripped out.

CSS in the http://www.w3.org/1999/xhtml  
namespace should always be left in.

@namespace "http://www.w3.org/1999/xhtml;;
.printui_app .PUITabContainer .tabs {
display: table;
table-layout: fixed;
width: 100%;
transform: translateY(5px);
padding-left:0px;
background-color: #4d4d4d;
margin-top:0px;
}
.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content {
/* background-color: white; */
position: relative;
width: 100%;
border-radius: 5px;
padding-left: 0px;
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
> On Jun 4, 2018, at 8:22 PM, Alex Harui  wrote:
> 
> I pushed a change that should fix that.
> 
> On 6/4/18, 1:40 AM, "Harbs"  wrote:
> 
>The following CSS:
> 
>TitleBar CloseButton
>{
>   width: 16px;
>   height: 16px;
>   margin: 0px;
>}
> 
>is output as:
> 
>.TitleBar CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>Instead of:
> 
>.TitleBar .CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>I think this is a bug.
> 
>Harbs
> 
>

AR standard

2018-06-04 Thread Dave Fisher

Hi Royale Peeps,

This standard looks interesting. It may be early, but what do you think?

https://www-engadget-com.cdn.ampproject.org/c/s/www.engadget.com/amp/2018/06/04/apple-pixar-adobe-standardized-ar-file-format/

Regards,
Dave

Sent from my iPhone

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  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  wrote:
>> 
>> I'm still not understanding.  Style.position is not inheriting so how would 
>> it cascade down?  Isn't .Application only applied to the ?
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 9:15 AM, "Harbs"  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  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0

>>> 
>>> 
>>> 
>> 
>> 
>> 
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

No. It’s one css selector in the CSS. No inline styles.

> On Jun 4, 2018, at 11:38 PM, Piotr Zarzycki  wrote:
> 
> Doing that does this mean that we are getting back to the previous state,
> where we have had position=relative everywhere ?
> 
> pon., 4 cze 2018 o 22:32 Harbs  napisał(a):
> 
>> 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  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how
>> would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  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 
>> 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"  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 
>> 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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 
 
 
 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

2018-06-04 Thread Piotr Zarzycki

Doing that does this mean that we are getting back to the previous state,
where we have had position=relative everywhere ?

pon., 4 cze 2018 o 22:32 Harbs  napisał(a):

> 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  wrote:
> >
> > I'm still not understanding.  Style.position is not inheriting so how
> would it cascade down?  Isn't .Application only applied to the ?
> >
> > Thanks,
> > -Alex
> >
> > On 6/4/18, 9:15 AM, "Harbs"  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 
> 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"  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 
> 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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: [royale-asjs] branch develop updated: Removed unselectable selector

The closest example that we have is probably DisabledBead and 
DisabledAlphaBead. The DisabledAlphaBead applies styling (i.e. an alpha) when 
the DisabledBead disables a component.

I was suggesting that there could be a UnselectableAppearance bead which gets 
applied together with the UnselectableBead and could apply CSS properties. That 
would free the user from having to know which selectors are used.

Harbs

> On Jun 4, 2018, at 7:24 PM, Alex Harui  wrote:
> 
> I think it is too early Monday for me.  I don't understand what you mean by 
> "styling could also be a bead".  How would folks discover the selector?
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 9:16 AM, "Harbs"  wrote:
> 
>Fair enough.
> 
>Of course the styling could also be a bead…
> 
>> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
>> 
>> IMO, it is easier for folks to know that there is a selector to override or 
>> add styles to if it is in one of our .css files instead of buried in code.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 9:11 AM, "Harbs" > > wrote:
>> 
>>> I don't know why someone would want to override unselectable styles, but 
>>> the first idea that popped into my head was a different background color so 
>>> folks knew not to even bother to select text in the unselectable controls.  
>>> Another possibility is that there are other styles that may be needed 
>>> someday that control how screen readers deal with unselectable controls.
>> 
>>   Ah. You mean add additional styles. There’s no reason they couldn’t add an 
>> additional .unselectable selector with styling elsewhere in the CSS. I could 
>> go either way on this. If folks feel strongly it should be a “proper” 
>> selector, I’ll do that.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>>> 
>>> Feel free to change the name of the bead so that the Type Selector name 
>>> looks "better".  I think we agreed to drop the "Bead" portion of names 
>>> going forward.
>>> 
>>> If you are absolutely sure nobody will ever need to override what is in 
>>> that selector, then I'm fine with injecting it with code and using the new 
>>> utility function you created, but otherwise, I would hope we try to write 
>>> the framework without injecting styles with code.  Having overrideable 
>>> selectors should be the recommended practice for a framework.  We want 
>>> everything to be override-able.
>>> 
>>> I don't know why someone would want to override unselectable styles, but 
>>> the first idea that popped into my head was a different background color so 
>>> folks knew not to even bother to select text in the unselectable controls.  
>>> Another possibility is that there are other styles that may be needed 
>>> someday that control how screen readers deal with unselectable controls.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:48 AM, "Harbs" >>  >> >> wrote:
>>> 
>>>  That would probably work. I’m not totally happy with that selector name.
>>> 
>>>  I can switch the implementation if you think that’s better. I’m not sure 
>>> why a user would override an “unelectable” style though.
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 6:45 PM, Alex Harui >>> > wrote:
 
 Hi Harbs,
 
 My suggestion for adding the selector is to make the selector look like a 
 Type/Element Selector with the name "UnselectableElementBead".  If you do 
 that, then wouldn't that selector be dropped out if nobody is using 
 UnselectableElementBead?
 
 I would hope we could find a solution that doesn't result in code 
 injecting styles as that sort of screws up users overriding those styles.
 
 My 2 cents,
 -Alex
 
 On 6/4/18, 1:14 AM, "Harbs" >>>  >   On Jun 4, 2018, at 10:24 AM, Carlos Rovira    >> wrote:
> 
> Hi,
> 
> I think as Alex that better way for this is the bead add the css style to
> classList.
> 
> thanks
> 
> 2018-06-04 6:33 GMT+02:00 Alex Harui    >>:
> 
>> IMO, the better fix would be to just rename the selector in defaults.css
>> to be UnselectableElementBead and have UnselectableElementBead add
>> "UnselectableElementBead" to the classList.
>> 
>> Or am I not understanding what

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Hi Carlos,

At this point, I think I've addressed all of the compiler issues that result in 
unnecessary output or processing.  If Harbs is finished with the framework 
changes, then I think we can try building Jewel with and without Basic and see 
if there are still issues.

I have to say that my understanding of your responses seem counter to how the 
main patterns in Royale's composition-based frameworks are supposed to work.  
Here are some of the disconnects as I see them.

1. Jewel Views, Models, Controllers and other beads should not be tied to Jewel 
TLCs.  TLCs are intended to be example compositions of beads.  See the 
"Exploded Component" section of "Terminology and Concepts".
2. Jewel Views should not be tied to Jewel Models.   Jewel may not even need 
its own Models for many controls.  The default TextButton model just has text 
and html properties.  There shouldn't be anything component-set-specific about 
such a model.
3. Folks are encouraged to create compositions from beads at all levels of the 
framework, from all component sets, in order to maximize code reuse.  So, if 
you want to split Basic beads into a separate SWC from Basic TLCs, you must 
also agree to split Jewel beads into a separate SWC away from Jewel TLCs.   
That way, folks who compose Jewel beads into another component set will enjoy 
the same benefits you are claiming will happen if we split Basic beads from 
Basic TLCs.
4. Because there are different levels of complexity, it does not make sense to 
try to make one universal library of re-usable pieces.  Also, because we want 
third-parties to have a viable ecosystem for their components, we want to make 
sure that composition works well in a decentralized organizational model.
5. Everything in Royale, even the TLCs need to be reusable.  The MXML Component 
model requires it, especially of TLCs.

I noticed just now that Jewel does not yet have any "composite" components 
(meaning, components composed of other components).  You may want to work on 
Jewel DataGrid, for example, and have it use the Express type-agnostic 
DataGridModel.  It might help illustrate how different levels of bead 
complexity should work.

My 2 cents,
-Alex

On 6/1/18, 1:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

2018-06-01 8:08 GMT+02:00 Alex Harui :
>
>
> Key word here is *optional* not *mandatory*. Take this in mind, since
> while
> I have the option to use it or not, I even should have the option to
> link
> it or not, since there's no obligation or requeriment to use.
>
> Everything is currently optional the way we have it, but the principle of
> code re-use is primary.

I think here can't agree. Until the refactor, I couldn't get rid off all
the Basic things I didn't want. Rigth now is truly optional. In all
possible views (code, css and library linking), while still you can take
the old route as well. Everybody wins here.

> Copying code to avoid a project dependency is not a recommended practice.
>

If I copy code is to change it. In the final picture you should never see
the same code. For example yesterday I notice the existence of UIDUtils,
that was almost the same code than RPCUIutils, so I removed the later. This
days I plan to work on jewel layouts. This code is already different, but
it will be even more, more CSS based and with more features. But it started
as a copy of similar layout code in Basic. I think that's a normal process.

>
> The Emulation set will use Basic beads for models and controllers and lots
> of other things, if the simple implementations suffice.
>

I think this will be difficult or at least I don't see how that will work.
If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
Button, not Basic Button, and the Jewel Theme. In general, Jewel controls
and components setup a concrete visual structure through "createElementwith
a concrete style structure that MXRoyale will need to replicate in code. So
Basic seems very far from this requirement. for complex components where
views are in place is more natural to use Jewel parts than go Basic. For
example Slider in Basic has a different approach than in Jewel, so trying
to make the visuals in Jewel work with Basic won't work.

I think to make this happen we should think not in actual Basic or Jewel
but in only one unified set that can rely less in createElement and more in
view implementations so we can have separated SWCs with Basic and Jewel
views.

> I mentioned this before.  The DataGridModel in Express is type-agnostic
> (dataProvider is Object) whereas in Basic is assumes the dataProvider is 
an
> Array.  And you can configure the Basic one to use different dataProviders
> of different types.  That's on purpose, for PAYG

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

Ok! Thanks, don't know that we already was using that repo.

Thanks!

2018-06-04 11:59 GMT+02:00 Harbs :

> The Royale build pulls the externs from that repo. We have lots of changes
> on top of Google externs that we need. We used to use patch files, but it
> was cumbersome. Applying the changes directly to a fork works better.
>
> I was just letting you know that if your build does not work, you might
> need to clear out your local cache.
>
> HTH,
> Harbs
>
> > On Jun 4, 2018, at 12:30 PM, Carlos Rovira 
> wrote:
> >
> > ok, but then don't understand that we have code that is not usable by our
> > own.
> > I think if that code can't be used, it should be as well in Royale-extras
> > libs, so people wanting to use should grab both the modified closure
> > compiler and the library with code that uses it
> >
> > make this sense?
> >
> > Thanks
> >
> > 2018-06-04 11:10 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
> >
> >> FYI, this requires changes to the externs committed here:
> >> https://github.com/royale-extras/closure-compiler/commit/ <
> https://github.com/royale-extras/closure-compiler/commit/>
> >> 323c6b5f37973fac2bd611bfeb6f80359e3bbc98  https://github.com/royale->
> >> extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80
> 359e3bbc98>
> >>
> >>> On Jun 4, 2018, at 12:04 PM, Carlos Rovira 
> >> wrote:
> >>>
> >>> Great! This seems to be very useful!
> >>>
> >>> thanks! :)
> >>>
> >>> 2018-06-04 10:22 GMT+02:00 :
> >>>
>  This is an automated email from the ASF dual-hosted git repository.
> 
>  harbs pushed a commit to branch develop
>  in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
>  The following commit(s) were added to refs/heads/develop by this push:
> new 50ca711  Added utility function to dynamically add CSS
> selectors
>  50ca711 is described below
> 
>  commit 50ca711de856475536ea26934023ccb2ebdfc360
>  Author: Harbs 
>  AuthorDate: Mon Jun 4 11:22:53 2018 +0300
> 
>    Added utility function to dynamically add CSS selectors
> 
>    I’m not sure if there’s a good way to do this for swf.
>  ---
>  .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
>  .../apache/royale/utils/css/addDynamicSelector.as  | 57
>  ++
>  2 files changed, 59 insertions(+)
> 
>  diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>  b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>  index a0a0b58..ee14d3a 100644
>  --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>  +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>  @@ -303,6 +303,8 @@ internal class CoreClasses
>    import org.apache.royale.utils.date.addSeconds; addSeconds;
>    import org.apache.royale.utils.date.addYears; addYears;
> 
>  +   import org.apache.royale.utils.css.addDynamicSelector;
>  addDynamicSelector;
>  +
> import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
> import org.apache.royale.utils.ClassSelectorList;
> >> ClassSelectorList;
>  }
>  diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
>  royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
>  src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
>  new file mode 100644
>  index 000..b7e495a
>  --- /dev/null
>  +++ b/frameworks/projects/Core/src/main/royale/org/apache/
>  royale/utils/css/addDynamicSelector.as
>  @@ -0,0 +1,57 @@
>  +///
>  /
>  +//
>  +//  Licensed to the Apache Software Foundation (ASF) under one or
> more
>  +//  contributor license agreements.  See the NOTICE file distributed
> >> with
>  +//  this work for additional information regarding copyright
> ownership.
>  +//  The ASF licenses this file to You under the Apache License,
> Version
>  2.0
>  +//  (the "License"); you may not use this file except in compliance
> >> with
>  +//  the License.  You may obtain a copy of the License at
>  +//
>  +//  http://www.apache.org/licenses/LICENSE-2.0
>  +//
>  +//  Unless required by applicable law or agreed to in writing,
> software
>  +//  distributed under the License is distributed on an "AS IS" BASIS,
>  +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>  implied.
>  +//  See the License for the specific language governing permissions
> and
>  +//  limitations under the License.
>  +//
>  +///
>  /
>  +package org.apache.royale.utils.css
>  +{
>  +import org.apache.royale.core.IUIBase;
>  +
>  +/**
>  + *  Adds a CSS selector dynamically at runtime.
>  + *
>

Re: Incorrect descendent CSS output

I pushed a change that should fix that.

On 6/4/18, 1:40 AM, "Harbs"  wrote:

The following CSS:

TitleBar CloseButton
{
width: 16px;
height: 16px;
margin: 0px;
}

is output as:

.TitleBar CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

Instead of:

.TitleBar .CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

I think this is a bug.

Harbs

Re: [royale-asjs] branch develop updated: Removed unselectable selector

I think it is too early Monday for me.  I don't understand what you mean by 
"styling could also be a bead".  How would folks discover the selector?

Thanks,
-Alex

On 6/4/18, 9:16 AM, "Harbs"  wrote:

Fair enough.

Of course the styling could also be a bead…

> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
> 
> IMO, it is easier for folks to know that there is a selector to override 
or add styles to if it is in one of our .css files instead of buried in code.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 9:11 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>> I don't know why someone would want to override unselectable styles, but 
the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.
> 
>Ah. You mean add additional styles. There’s no reason they couldn’t 
add an additional .unselectable selector with styling elsewhere in the CSS. I 
could go either way on this. If folks feel strongly it should be a “proper” 
selector, I’ll do that.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>> 
>> Feel free to change the name of the bead so that the Type Selector name 
looks "better".  I think we agreed to drop the "Bead" portion of names going 
forward.
>> 
>> If you are absolutely sure nobody will ever need to override what is in 
that selector, then I'm fine with injecting it with code and using the new 
utility function you created, but otherwise, I would hope we try to write the 
framework without injecting styles with code.  Having overrideable selectors 
should be the recommended practice for a framework.  We want everything to be 
override-able.
>> 
>> I don't know why someone would want to override unselectable styles, but 
the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 8:48 AM, "Harbs" mailto:harbs.li...@gmail.com> >> wrote:
>> 
>>   That would probably work. I’m not totally happy with that selector 
name.
>> 
>>   I can switch the implementation if you think that’s better. I’m not 
sure why a user would override an “unelectable” style though.
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 6:45 PM, Alex Harui mailto:aha...@adobe.com.INVALID>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> My suggestion for adding the selector is to make the selector look like 
a Type/Element Selector with the name "UnselectableElementBead".  If you do 
that, then wouldn't that selector be dropped out if nobody is using 
UnselectableElementBead?
>>> 
>>> I would hope we could find a solution that doesn't result in code 
injecting styles as that sort of screws up users overriding those styles.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 1:14 AM, "Harbs" mailto:harbs.li...@gmail.com> >  >> 
>>>  It does add the style to the class list.
>>> 
>>>  The only question is how to add the selector to the CSS.
>>> 
>>>  Thanks,
>>>  Harbs
>>> 
 On Jun 4, 2018, at 10:24 AM, Carlos Rovira mailto:carlosrov...@apache.org> >> wrote:
 
 Hi,
 
 I think as Alex that better way for this is the bead add the css style 
to
 classList.
 
 thanks
 
 2018-06-04 6:33 GMT+02:00 Alex Harui mailto:aha...@adobe.com.invalid> >>:
 
> IMO, the better fix would be to just rename the selector in 
defaults.css
> to be UnselectableElementBead and have UnselectableElementBead add
> "UnselectableElementBead" to the classList.
> 
> Or am I not understanding what this does?
> 
> -Alex
> 
> 
> On 6/2/18, 1:59 PM, "Harbs" mailto:harbs.li...@gmail.com> >> wrote:
> 
> What I really wanted to do here was create some self invoking code
> which was run when the UnselectableElementBead class was loaded.
> 
> Is there any way of doing

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

I'm still not understanding.  Style.position is not inheriting so how would it 
cascade down?  Isn't .Application only applied to the ?

Thanks,
-Alex

On 6/4/18, 9:15 AM, "Harbs"  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  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>> 
>> 
> 
> 
>

Re: [royale-asjs] branch develop updated: Removed unselectable selector

Fair enough.

Of course the styling could also be a bead…

> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
> 
> IMO, it is easier for folks to know that there is a selector to override or 
> add styles to if it is in one of our .css files instead of buried in code.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 9:11 AM, "Harbs"  > wrote:
> 
>> I don't know why someone would want to override unselectable styles, but the 
>> first idea that popped into my head was a different background color so 
>> folks knew not to even bother to select text in the unselectable controls.  
>> Another possibility is that there are other styles that may be needed 
>> someday that control how screen readers deal with unselectable controls.
> 
>Ah. You mean add additional styles. There’s no reason they couldn’t add an 
> additional .unselectable selector with styling elsewhere in the CSS. I could 
> go either way on this. If folks feel strongly it should be a “proper” 
> selector, I’ll do that.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>> 
>> Feel free to change the name of the bead so that the Type Selector name 
>> looks "better".  I think we agreed to drop the "Bead" portion of names going 
>> forward.
>> 
>> If you are absolutely sure nobody will ever need to override what is in that 
>> selector, then I'm fine with injecting it with code and using the new 
>> utility function you created, but otherwise, I would hope we try to write 
>> the framework without injecting styles with code.  Having overrideable 
>> selectors should be the recommended practice for a framework.  We want 
>> everything to be override-able.
>> 
>> I don't know why someone would want to override unselectable styles, but the 
>> first idea that popped into my head was a different background color so 
>> folks knew not to even bother to select text in the unselectable controls.  
>> Another possibility is that there are other styles that may be needed 
>> someday that control how screen readers deal with unselectable controls.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 8:48 AM, "Harbs" >  > >> wrote:
>> 
>>   That would probably work. I’m not totally happy with that selector name.
>> 
>>   I can switch the implementation if you think that’s better. I’m not sure 
>> why a user would override an “unelectable” style though.
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 6:45 PM, Alex Harui >> > wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> My suggestion for adding the selector is to make the selector look like a 
>>> Type/Element Selector with the name "UnselectableElementBead".  If you do 
>>> that, then wouldn't that selector be dropped out if nobody is using 
>>> UnselectableElementBead?
>>> 
>>> I would hope we could find a solution that doesn't result in code injecting 
>>> styles as that sort of screws up users overriding those styles.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 1:14 AM, "Harbs" >>  >> > >>  >> >> 
>>>  It does add the style to the class list.
>>> 
>>>  The only question is how to add the selector to the CSS.
>>> 
>>>  Thanks,
>>>  Harbs
>>> 
 On Jun 4, 2018, at 10:24 AM, Carlos Rovira >>>  >> wrote:
 
 Hi,
 
 I think as Alex that better way for this is the bead add the css style to
 classList.
 
 thanks
 
 2018-06-04 6:33 GMT+02:00 Alex Harui >>>  >>:
 
> IMO, the better fix would be to just rename the selector in defaults.css
> to be UnselectableElementBead and have UnselectableElementBead add
> "UnselectableElementBead" to the classList.
> 
> Or am I not understanding what this does?
> 
> -Alex
> 
> 
> On 6/2/18, 1:59 PM, "Harbs"    >> wrote:
> 
> What I really wanted to do here was create some self invoking code
> which was run when the UnselectableElementBead class was loaded.
> 
> Is there any way of doing that without writing a static method and
> invoking that?
> 
> Thanks,
> Harbs
> 
> 
>> On Jun 2, 2018, at 11:39 PM, ha...@apache.org  
>> > wrote:
>> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> harbs pushed a commit to branch develop
>> in repository

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

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  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>> 
>> 
> 
> 
>

Re: [royale-asjs] branch develop updated: Removed unselectable selector

IMO, it is easier for folks to know that there is a selector to override or add 
styles to if it is in one of our .css files instead of buried in code.

My 2 cents,
-Alex

On 6/4/18, 9:11 AM, "Harbs"  wrote:

> I don't know why someone would want to override unselectable styles, but 
the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.

Ah. You mean add additional styles. There’s no reason they couldn’t add an 
additional .unselectable selector with styling elsewhere in the CSS. I could go 
either way on this. If folks feel strongly it should be a “proper” selector, 
I’ll do that.

Thanks,
Harbs

> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
> 
> Feel free to change the name of the bead so that the Type Selector name 
looks "better".  I think we agreed to drop the "Bead" portion of names going 
forward.
> 
> If you are absolutely sure nobody will ever need to override what is in 
that selector, then I'm fine with injecting it with code and using the new 
utility function you created, but otherwise, I would hope we try to write the 
framework without injecting styles with code.  Having overrideable selectors 
should be the recommended practice for a framework.  We want everything to be 
override-able.
> 
> I don't know why someone would want to override unselectable styles, but 
the first idea that popped into my head was a different background color so 
folks knew not to even bother to select text in the unselectable controls.  
Another possibility is that there are other styles that may be needed someday 
that control how screen readers deal with unselectable controls.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:48 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>That would probably work. I’m not totally happy with that selector 
name.
> 
>I can switch the implementation if you think that’s better. I’m not 
sure why a user would override an “unelectable” style though.
> 
>Harbs
> 
>> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
>> 
>> Hi Harbs,
>> 
>> My suggestion for adding the selector is to make the selector look like 
a Type/Element Selector with the name "UnselectableElementBead".  If you do 
that, then wouldn't that selector be dropped out if nobody is using 
UnselectableElementBead?
>> 
>> I would hope we could find a solution that doesn't result in code 
injecting styles as that sort of screws up users overriding those styles.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 1:14 AM, "Harbs" mailto:harbs.li...@gmail.com> >> wrote:
>> 
>>   It does add the style to the class list.
>> 
>>   The only question is how to add the selector to the CSS.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira mailto:carlosrov...@apache.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I think as Alex that better way for this is the bead add the css style 
to
>>> classList.
>>> 
>>> thanks
>>> 
>>> 2018-06-04 6:33 GMT+02:00 Alex Harui mailto:aha...@adobe.com.invalid>>:
>>> 
 IMO, the better fix would be to just rename the selector in 
defaults.css
 to be UnselectableElementBead and have UnselectableElementBead add
 "UnselectableElementBead" to the classList.
 
 Or am I not understanding what this does?
 
 -Alex
 
 
 On 6/2/18, 1:59 PM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
 
  What I really wanted to do here was create some self invoking code
 which was run when the UnselectableElementBead class was loaded.
 
  Is there any way of doing that without writing a static method and
 invoking that?
 
  Thanks,
  Harbs
 
 
> On Jun 2, 2018, at 11:39 PM, ha...@apache.org 
 wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url= 

 https%3A%2F%2Fgitbox.apache.org 
%2Frepos%2Fasf%2Froyale-
 asjs.git=02%7C01%7Caharui%40adobe.com

Re: [royale-asjs] branch develop updated: Removed unselectable selector

> I don't know why someone would want to override unselectable styles, but the 
> first idea that popped into my head was a different background color so folks 
> knew not to even bother to select text in the unselectable controls.  Another 
> possibility is that there are other styles that may be needed someday that 
> control how screen readers deal with unselectable controls.

Ah. You mean add additional styles. There’s no reason they couldn’t add an 
additional .unselectable selector with styling elsewhere in the CSS. I could go 
either way on this. If folks feel strongly it should be a “proper” selector, 
I’ll do that.

Thanks,
Harbs

> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
> 
> Feel free to change the name of the bead so that the Type Selector name looks 
> "better".  I think we agreed to drop the "Bead" portion of names going 
> forward.
> 
> If you are absolutely sure nobody will ever need to override what is in that 
> selector, then I'm fine with injecting it with code and using the new utility 
> function you created, but otherwise, I would hope we try to write the 
> framework without injecting styles with code.  Having overrideable selectors 
> should be the recommended practice for a framework.  We want everything to be 
> override-able.
> 
> I don't know why someone would want to override unselectable styles, but the 
> first idea that popped into my head was a different background color so folks 
> knew not to even bother to select text in the unselectable controls.  Another 
> possibility is that there are other styles that may be needed someday that 
> control how screen readers deal with unselectable controls.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:48 AM, "Harbs"  > wrote:
> 
>That would probably work. I’m not totally happy with that selector name.
> 
>I can switch the implementation if you think that’s better. I’m not sure 
> why a user would override an “unelectable” style though.
> 
>Harbs
> 
>> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
>> 
>> Hi Harbs,
>> 
>> My suggestion for adding the selector is to make the selector look like a 
>> Type/Element Selector with the name "UnselectableElementBead".  If you do 
>> that, then wouldn't that selector be dropped out if nobody is using 
>> UnselectableElementBead?
>> 
>> I would hope we could find a solution that doesn't result in code injecting 
>> styles as that sort of screws up users overriding those styles.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 1:14 AM, "Harbs" >  > >> wrote:
>> 
>>   It does add the style to the class list.
>> 
>>   The only question is how to add the selector to the CSS.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I think as Alex that better way for this is the bead add the css style to
>>> classList.
>>> 
>>> thanks
>>> 
>>> 2018-06-04 6:33 GMT+02:00 Alex Harui >> >:
>>> 
 IMO, the better fix would be to just rename the selector in defaults.css
 to be UnselectableElementBead and have UnselectableElementBead add
 "UnselectableElementBead" to the classList.
 
 Or am I not understanding what this does?
 
 -Alex
 
 
 On 6/2/18, 1:59 PM, "Harbs" >>> > wrote:
 
  What I really wanted to do here was create some self invoking code
 which was run when the UnselectableElementBead class was loaded.
 
  Is there any way of doing that without writing a static method and
 invoking that?
 
  Thanks,
  Harbs
 
 
> On Jun 2, 2018, at 11:39 PM, ha...@apache.org  
> wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url= 
> 
 https%3A%2F%2Fgitbox.apache.org 
 %2Frepos%2Fasf%2Froyale-
 asjs.git=02%7C01%7Caharui%40adobe.com 
 %7C9369538a50114755520308d5c8cb
 b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
 Kj3OwfvmWh%2Bzk%3D=0
> 
> 
> The following commit(s) were added to refs/heads/develop by this
 push:
>  new b157ecf  Removed unselectable selector
> b157ecf is described below
> 
> commit b157ecff5ea11ff2035e105f266b0925c1970005
> Author: Harbs mailto:ha...@in-tools.com>>
> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
> 
> Removed unselectable selector
> ---
> .../projects/Basic/src/main/resources/defaults.css |  9 -
> .../royale/html/beads/UnselectableElementBead.as   | 22

Re: [royale-asjs] branch develop updated: remove invalid "; utf8" in all inlined svg images

Hi Harbs,

I think I tried that but not worked for inline SVG in CSS
SVG inlined is a very fragile feature, and is not supported well cross
browser.

Maybe I'll give it a try again since I'm getting a blocking issue in IE11,
I think is this [1]
and can't get it working. IE11 does not process inline styles in SVG.

Maybe getting to load the SVG can make it work, but I think I can find
again the problem that made
me go the actual route.

Let's see what happen. IE11 is a real pain to make ir work... :_(


[1] https://github.com/kisenka/svg-sprite-loader/issues/163


2018-06-04 12:33 GMT+02:00 Harbs :

> Looking at the Jewel themes, I thought of a possible suggestion for
> specifying SVG color:
>
> Instead of inlining  fill='#{encodecolor($primary-color)}’, I’m wondering
> if it might be better to give the elements a class. Something like this:
>
> 
>
> and elsewhere:
> .primary-fill{
>fill: $primary-color;
> }
>
> The same for secondary, strokes, etc.
>
> It might even make sense to specify classes for primary and secondary
> colors and background colors, etc.
>
> Doing so, might make it easier to swap color schemes. It’ll probably also
> result in simpler CSS.
>
> Just a thought, :-)
> Harbs
>
> > On Jun 4, 2018, at 1:19 PM, carlosrov...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > carlosrovira pushed a commit to branch develop
> > in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >
> >
> > The following commit(s) were added to refs/heads/develop by this push:
> > new 9525660  remove invalid ";utf8" in all inlined svg images
> > new db4b818  Merge branch 'develop' of https://github.com/apache/
> royale-asjs into develop
> > 9525660 is described below
> >
> > commit 95256606096972af65d00a578741afd697a39c1e
> > Author: Carlos Rovira 
> > AuthorDate: Mon Jun 4 12:18:50 2018 +0200
> >
> >remove invalid ";utf8" in all inlined svg images
> > ---
> > frameworks/themes/JewelTheme/src/main/resources/defaults.css | 12
> ++--
> > .../src/main/sass/components-primary/_checkbox.sass  | 10
> +-
> > .../src/main/sass/components-primary/_radiobutton.sass   | 10
> +-
> > .../JewelTheme/src/main/sass/components-primary/_slider.sass |  2 +-
> > 4 files changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> > index 0663ee5..253b8c0 100644
> > --- a/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> > +++ b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> > @@ -236,14 +236,14 @@ j|Card {
> >   border-radius: 3px;
> > }
> > .jewel.checkbox input:checked, .jewel.checkbox input:checked:active {
> > -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #f8f8f8;
> > +  background: url("data:image/svg+xml, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #f8f8f8;
> >   background-repeat: no-repeat;
> >   background-size: 90%;
> >   background-position: center;
> >   background-attachment: fixed;
> > }
> > .jewel.checkbox input:checked:checked:focus, .jewel.checkbox
> input:checked:checked:active:focus, .jewel.checkbox
> input:checked:active:checked:focus, .jewel.checkbox
> input:checked:active:checked:active:focus {
> > -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #b3dffa;
> > +  background: url("data:image/svg+xml, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #b3dffa;
> >   background-repeat: no-repeat;
> >   background-size: 90%;
> >   background-position: center;
> > @@ -263,7 +263,7 @@ j|Card {
> >   color: silver;
> > }
> > .jewel.checkbox input[disabled]:checked {
> > -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #f3f3f3;
> > +  background: url("data:image/svg+xml, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'>"), #f3f3f3;
> >   background-size: 90%;
> >   background-position: center;
> >   background-repeat: no-repeat;
> > @@ -371,14 +371,14 @@ j|Card {
> >   border-radius: 50%;
> > }
> > .jewel.radiobutton input:checked, .jewel.radiobutton
> input:checked:active {
> > -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-616, -350)'> r='6'>"), #f8f8f8;
> > +  background: url("data:image/svg+xml, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-616, -350)'> r='6'>"), #f8f8f8;
> >   background-repeat: no-repeat;
> >   background-size: 60%;
> >   background-position: center;
> >   background-attachment: fixed;
> > }
> > .jewel.radiobutton input:checked:checked:focus, .jewel.radiobutton
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
>

Re: [royale-asjs] branch develop updated: Removed unselectable selector

Feel free to change the name of the bead so that the Type Selector name looks 
"better".  I think we agreed to drop the "Bead" portion of names going forward.

If you are absolutely sure nobody will ever need to override what is in that 
selector, then I'm fine with injecting it with code and using the new utility 
function you created, but otherwise, I would hope we try to write the framework 
without injecting styles with code.  Having overrideable selectors should be 
the recommended practice for a framework.  We want everything to be 
override-able.

I don't know why someone would want to override unselectable styles, but the 
first idea that popped into my head was a different background color so folks 
knew not to even bother to select text in the unselectable controls.  Another 
possibility is that there are other styles that may be needed someday that 
control how screen readers deal with unselectable controls.

My 2 cents,
-Alex

On 6/4/18, 8:48 AM, "Harbs"  wrote:

That would probably work. I’m not totally happy with that selector name.

I can switch the implementation if you think that’s better. I’m not sure 
why a user would override an “unelectable” style though.

Harbs

> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
> 
> Hi Harbs,
> 
> My suggestion for adding the selector is to make the selector look like a 
Type/Element Selector with the name "UnselectableElementBead".  If you do that, 
then wouldn't that selector be dropped out if nobody is using 
UnselectableElementBead?
> 
> I would hope we could find a solution that doesn't result in code 
injecting styles as that sort of screws up users overriding those styles.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 1:14 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>It does add the style to the class list.
> 
>The only question is how to add the selector to the CSS.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  
wrote:
>> 
>> Hi,
>> 
>> I think as Alex that better way for this is the bead add the css style to
>> classList.
>> 
>> thanks
>> 
>> 2018-06-04 6:33 GMT+02:00 Alex Harui :
>> 
>>> IMO, the better fix would be to just rename the selector in defaults.css
>>> to be UnselectableElementBead and have UnselectableElementBead add
>>> "UnselectableElementBead" to the classList.
>>> 
>>> Or am I not understanding what this does?
>>> 
>>> -Alex
>>> 
>>> 
>>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>>> 
>>>   What I really wanted to do here was create some self invoking code
>>> which was run when the UnselectableElementBead class was loaded.
>>> 
>>>   Is there any way of doing that without writing a static method and
>>> invoking that?
>>> 
>>>   Thanks,
>>>   Harbs
>>> 
>>> 
 On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
 
 This is an automated email from the ASF dual-hosted git repository.
 
 harbs pushed a commit to branch develop
 in repository https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-
>>> 
asjs.git=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>>> Kj3OwfvmWh%2Bzk%3D=0
 
 
 The following commit(s) were added to refs/heads/develop by this
>>> push:
   new b157ecf  Removed unselectable selector
 b157ecf is described below
 
 commit b157ecff5ea11ff2035e105f266b0925c1970005
 Author: Harbs 
 AuthorDate: Sat Jun 2 23:39:28 2018 +0300
 
  Removed unselectable selector
 ---
 .../projects/Basic/src/main/resources/defaults.css |  9 -
 .../royale/html/beads/UnselectableElementBead.as   | 22
>>> ++
 2 files changed, 22 insertions(+), 9 deletions(-)
 
 diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> b/frameworks/projects/Basic/src/main/resources/defaults.css
 index ea02120..23a324d 100644
 --- a/frameworks/projects/Basic/src/main/resources/defaults.css
 +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
 @@ -26,15 +26,6 @@
 box-sizing: border-box;
 }
 
 -.unselectable
 -{
 - -moz-user-select: -moz-none;
 - -khtml-user-select: none;
 - -webkit-user-select: none;
 - -o-user-select: none;
 - user-select: none;
 -}
 -
 Alert
 {
 IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>>> VerticalFlexLayout");
 diff --git

Re: [royale-asjs] branch develop updated: Removed unselectable selector

That would probably work. I’m not totally happy with that selector name.

I can switch the implementation if you think that’s better. I’m not sure why a 
user would override an “unelectable” style though.

Harbs

> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
> 
> Hi Harbs,
> 
> My suggestion for adding the selector is to make the selector look like a 
> Type/Element Selector with the name "UnselectableElementBead".  If you do 
> that, then wouldn't that selector be dropped out if nobody is using 
> UnselectableElementBead?
> 
> I would hope we could find a solution that doesn't result in code injecting 
> styles as that sort of screws up users overriding those styles.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 1:14 AM, "Harbs"  > wrote:
> 
>It does add the style to the class list.
> 
>The only question is how to add the selector to the CSS.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  wrote:
>> 
>> Hi,
>> 
>> I think as Alex that better way for this is the bead add the css style to
>> classList.
>> 
>> thanks
>> 
>> 2018-06-04 6:33 GMT+02:00 Alex Harui :
>> 
>>> IMO, the better fix would be to just rename the selector in defaults.css
>>> to be UnselectableElementBead and have UnselectableElementBead add
>>> "UnselectableElementBead" to the classList.
>>> 
>>> Or am I not understanding what this does?
>>> 
>>> -Alex
>>> 
>>> 
>>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>>> 
>>>   What I really wanted to do here was create some self invoking code
>>> which was run when the UnselectableElementBead class was loaded.
>>> 
>>>   Is there any way of doing that without writing a static method and
>>> invoking that?
>>> 
>>>   Thanks,
>>>   Harbs
>>> 
>>> 
 On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
 
 This is an automated email from the ASF dual-hosted git repository.
 
 harbs pushed a commit to branch develop
 in repository https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-
>>> asjs.git=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>>> Kj3OwfvmWh%2Bzk%3D=0
 
 
 The following commit(s) were added to refs/heads/develop by this
>>> push:
   new b157ecf  Removed unselectable selector
 b157ecf is described below
 
 commit b157ecff5ea11ff2035e105f266b0925c1970005
 Author: Harbs 
 AuthorDate: Sat Jun 2 23:39:28 2018 +0300
 
  Removed unselectable selector
 ---
 .../projects/Basic/src/main/resources/defaults.css |  9 -
 .../royale/html/beads/UnselectableElementBead.as   | 22
>>> ++
 2 files changed, 22 insertions(+), 9 deletions(-)
 
 diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> b/frameworks/projects/Basic/src/main/resources/defaults.css
 index ea02120..23a324d 100644
 --- a/frameworks/projects/Basic/src/main/resources/defaults.css
 +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
 @@ -26,15 +26,6 @@
 box-sizing: border-box;
 }
 
 -.unselectable
 -{
 - -moz-user-select: -moz-none;
 - -khtml-user-select: none;
 - -webkit-user-select: none;
 - -o-user-select: none;
 - user-select: none;
 -}
 -
 Alert
 {
 IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>>> VerticalFlexLayout");
 diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>>> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
>>> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
 index 6697472..c80c907 100644
 --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>>> royale/html/beads/UnselectableElementBead.as
 +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>>> royale/html/beads/UnselectableElementBead.as
 @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
 public class UnselectableElementBead implements IBead
 {
 /**
 +  * @royaleignorecoercion HTMLStyleElement
 +  */
 + private static function insertRule():void
 + {
 + // only do this once...
 + if(ruleInserted)
 + return;
 + ruleInserted = true;
 + // Inject a new css selector
 + COMPILE::JS
 + {
 + var style:HTMLStyleElement =
>>> document.createElement('style') as HTMLStyleElement;
 + style.type = 'text/css';
 + style.innerHTML = '.unselectable
>>> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select:
>>> none;user-select: none;}';
 +

Re: [royale-asjs] branch develop updated: Removed unselectable selector

Hi Harbs,

My suggestion for adding the selector is to make the selector look like a 
Type/Element Selector with the name "UnselectableElementBead".  If you do that, 
then wouldn't that selector be dropped out if nobody is using 
UnselectableElementBead?

I would hope we could find a solution that doesn't result in code injecting 
styles as that sort of screws up users overriding those styles.

My 2 cents,
-Alex

On 6/4/18, 1:14 AM, "Harbs"  wrote:

It does add the style to the class list.

The only question is how to add the selector to the CSS.

Thanks,
Harbs

> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  
wrote:
> 
> Hi,
> 
> I think as Alex that better way for this is the bead add the css style to
> classList.
> 
> thanks
> 
> 2018-06-04 6:33 GMT+02:00 Alex Harui :
> 
>> IMO, the better fix would be to just rename the selector in defaults.css
>> to be UnselectableElementBead and have UnselectableElementBead add
>> "UnselectableElementBead" to the classList.
>> 
>> Or am I not understanding what this does?
>> 
>> -Alex
>> 
>> 
>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>> 
>>What I really wanted to do here was create some self invoking code
>> which was run when the UnselectableElementBead class was loaded.
>> 
>>Is there any way of doing that without writing a static method and
>> invoking that?
>> 
>>Thanks,
>>Harbs
>> 
>> 
>>> On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-
>> asjs.git=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>> Kj3OwfvmWh%2Bzk%3D=0
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/develop by this
>> push:
>>>new b157ecf  Removed unselectable selector
>>> b157ecf is described below
>>> 
>>> commit b157ecff5ea11ff2035e105f266b0925c1970005
>>> Author: Harbs 
>>> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
>>> 
>>>   Removed unselectable selector
>>> ---
>>> .../projects/Basic/src/main/resources/defaults.css |  9 -
>>> .../royale/html/beads/UnselectableElementBead.as   | 22
>> ++
>>> 2 files changed, 22 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>> b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> index ea02120..23a324d 100644
>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> @@ -26,15 +26,6 @@
>>>  box-sizing: border-box;
>>> }
>>> 
>>> -.unselectable
>>> -{
>>> - -moz-user-select: -moz-none;
>>> - -khtml-user-select: none;
>>> - -webkit-user-select: none;
>>> - -o-user-select: none;
>>> - user-select: none;
>>> -}
>>> -
>>> Alert
>>> {
>>>  IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>> VerticalFlexLayout");
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
>> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>>> index 6697472..c80c907 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
>>>  public class UnselectableElementBead implements IBead
>>>  {
>>>  /**
>>> +  * @royaleignorecoercion HTMLStyleElement
>>> +  */
>>> + private static function insertRule():void
>>> + {
>>> + // only do this once...
>>> + if(ruleInserted)
>>> + return;
>>> + ruleInserted = true;
>>> + // Inject a new css selector
>>> + COMPILE::JS
>>> + {
>>> + var style:HTMLStyleElement =
>> document.createElement('style') as HTMLStyleElement;
>>> + style.type = 'text/css';
>>> + style.innerHTML = '.unselectable
>> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select:
>> none;user-select: none;}';
>>> +

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

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  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"  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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

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" 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=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

2018-06-04 Thread yishayw

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: http://apache-royale-development.20373.n8.nabble.com/

Re: Last class selectors

FYI, I just compiled a bare-bones app, and a Basic app with a View, VContainer 
and Label is 85KB uncompressed. 24KB gzipped. It looks like there’s no extra 
classes. 

The CSS is 546 bytes and 222 bytes gzipped. There’s no extra css either, 
although som empty selectors could use some cleanup.

Harbs

> On Jun 4, 2018, at 4:27 PM, Harbs  wrote:
> 
> The only class selectors left in Basic defaults.css is:
> 
> .Application *, .royale *, . royale *:before, . royale *:after {
>   -moz-box-sizing: border-box;
>   -webkit-box-sizing: border-box;
>   box-sizing: border-box;
> }
> 
> I’m not sure how to best get rid of this.
> 
> Thoughts?
> Harbs

Last class selectors

The only class selectors left in Basic defaults.css is:

.Application *, .royale *, . royale *:before, . royale *:after {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

I’m not sure how to best get rid of this.

Thoughts?
Harbs

Re: [royale-asjs] branch develop updated: remove invalid "; utf8" in all inlined svg images

Looking at the Jewel themes, I thought of a possible suggestion for specifying 
SVG color:

Instead of inlining  fill='#{encodecolor($primary-color)}’, I’m wondering if it 
might be better to give the elements a class. Something like this:



and elsewhere:
.primary-fill{
   fill: $primary-color;
}

The same for secondary, strokes, etc.

It might even make sense to specify classes for primary and secondary colors 
and background colors, etc.

Doing so, might make it easier to swap color schemes. It’ll probably also 
result in simpler CSS.

Just a thought, :-)
Harbs

> On Jun 4, 2018, at 1:19 PM, carlosrov...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> carlosrovira pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 9525660  remove invalid ";utf8" in all inlined svg images
> new db4b818  Merge branch 'develop' of 
> https://github.com/apache/royale-asjs into develop
> 9525660 is described below
> 
> commit 95256606096972af65d00a578741afd697a39c1e
> Author: Carlos Rovira 
> AuthorDate: Mon Jun 4 12:18:50 2018 +0200
> 
>remove invalid ";utf8" in all inlined svg images
> ---
> frameworks/themes/JewelTheme/src/main/resources/defaults.css | 12 ++--
> .../src/main/sass/components-primary/_checkbox.sass  | 10 +-
> .../src/main/sass/components-primary/_radiobutton.sass   | 10 +-
> .../JewelTheme/src/main/sass/components-primary/_slider.sass |  2 +-
> 4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/frameworks/themes/JewelTheme/src/main/resources/defaults.css 
> b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> index 0663ee5..253b8c0 100644
> --- a/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> +++ b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> @@ -236,14 +236,14 @@ j|Card {
>   border-radius: 3px;
> }
> .jewel.checkbox input:checked, .jewel.checkbox input:checked:active {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%233CADF1' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #f8f8f8;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #f8f8f8;
>   background-repeat: no-repeat;
>   background-size: 90%;
>   background-position: center;
>   background-attachment: fixed;
> }
> .jewel.checkbox input:checked:checked:focus, .jewel.checkbox 
> input:checked:checked:active:focus, .jewel.checkbox 
> input:checked:active:checked:focus, .jewel.checkbox 
> input:checked:active:checked:active:focus {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%233CADF1' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #b3dffa;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #b3dffa;
>   background-repeat: no-repeat;
>   background-size: 90%;
>   background-position: center;
> @@ -263,7 +263,7 @@ j|Card {
>   color: silver;
> }
> .jewel.checkbox input[disabled]:checked {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%23cc' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #f3f3f3;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #f3f3f3;
>   background-size: 90%;
>   background-position: center;
>   background-repeat: no-repeat;
> @@ -371,14 +371,14 @@ j|Card {
>   border-radius: 50%;
> }
> .jewel.radiobutton input:checked, .jewel.radiobutton input:checked:active {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-616, -350)'> fill='%233CADF1' cx='11' cy='11' r='6'>"), #f8f8f8;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(611, 345)'> r='6'>"), #f8f8f8;
>   background-repeat: no-repeat;
>   background-size: 60%;
>   background-position: center;
>   background-attachment: fixed;
> }
> .jewel.radiobutton input:checked:checked:focus, .jewel.radiobutton 
> input:checked:checked:active:focus, .jewel.radiobutton 
> input:checked:active:checked:focus, .jewel.radiobutton 
> input:checked:active:checked:active:focus {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-616, -350)'> fill='%233CADF1' cx='11' cy='11' r='6'>"), #b3dffa;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(611, 345)'> r='6'>"), #b3dffa;
>   background-repeat: no-repeat;
>   background-size: 60%;
>   background-position: center;
> @@ -398,7 +398,7 @@ j|Card {
>   color: silver;
> }
>

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

The Royale build pulls the externs from that repo. We have lots of changes on 
top of Google externs that we need. We used to use patch files, but it was 
cumbersome. Applying the changes directly to a fork works better.

I was just letting you know that if your build does not work, you might need to 
clear out your local cache.

HTH,
Harbs

> On Jun 4, 2018, at 12:30 PM, Carlos Rovira  wrote:
> 
> ok, but then don't understand that we have code that is not usable by our
> own.
> I think if that code can't be used, it should be as well in Royale-extras
> libs, so people wanting to use should grab both the modified closure
> compiler and the library with code that uses it
> 
> make this sense?
> 
> Thanks
> 
> 2018-06-04 11:10 GMT+02:00 Harbs  >:
> 
>> FYI, this requires changes to the externs committed here:
>> https://github.com/royale-extras/closure-compiler/commit/ 
>> 
>> 323c6b5f37973fac2bd611bfeb6f80359e3bbc98 > 
>> extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98>
>> 
>>> On Jun 4, 2018, at 12:04 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Great! This seems to be very useful!
>>> 
>>> thanks! :)
>>> 
>>> 2018-06-04 10:22 GMT+02:00 :
>>> 
 This is an automated email from the ASF dual-hosted git repository.
 
 harbs pushed a commit to branch develop
 in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
 
 
 The following commit(s) were added to refs/heads/develop by this push:
new 50ca711  Added utility function to dynamically add CSS selectors
 50ca711 is described below
 
 commit 50ca711de856475536ea26934023ccb2ebdfc360
 Author: Harbs 
 AuthorDate: Mon Jun 4 11:22:53 2018 +0300
 
   Added utility function to dynamically add CSS selectors
 
   I’m not sure if there’s a good way to do this for swf.
 ---
 .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
 .../apache/royale/utils/css/addDynamicSelector.as  | 57
 ++
 2 files changed, 59 insertions(+)
 
 diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
 b/frameworks/projects/Core/src/main/royale/CoreClasses.as
 index a0a0b58..ee14d3a 100644
 --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
 +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
 @@ -303,6 +303,8 @@ internal class CoreClasses
   import org.apache.royale.utils.date.addSeconds; addSeconds;
   import org.apache.royale.utils.date.addYears; addYears;
 
 +   import org.apache.royale.utils.css.addDynamicSelector;
 addDynamicSelector;
 +
import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
import org.apache.royale.utils.ClassSelectorList;
>> ClassSelectorList;
 }
 diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
 royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
 src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
 new file mode 100644
 index 000..b7e495a
 --- /dev/null
 +++ b/frameworks/projects/Core/src/main/royale/org/apache/
 royale/utils/css/addDynamicSelector.as
 @@ -0,0 +1,57 @@
 +///
 /
 +//
 +//  Licensed to the Apache Software Foundation (ASF) under one or more
 +//  contributor license agreements.  See the NOTICE file distributed
>> with
 +//  this work for additional information regarding copyright ownership.
 +//  The ASF licenses this file to You under the Apache License, Version
 2.0
 +//  (the "License"); you may not use this file except in compliance
>> with
 +//  the License.  You may obtain a copy of the License at
 +//
 +//  http://www.apache.org/licenses/LICENSE-2.0
 +//
 +//  Unless required by applicable law or agreed to in writing, software
 +//  distributed under the License is distributed on an "AS IS" BASIS,
 +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
 implied.
 +//  See the License for the specific language governing permissions and
 +//  limitations under the License.
 +//
 +///
 /
 +package org.apache.royale.utils.css
 +{
 +import org.apache.royale.core.IUIBase;
 +
 +/**
 + *  Adds a CSS selector dynamically at runtime.
 + *
 + *  @param selector The CSS selector.
 + *
 + *  @param rule The CSS rule to apply.
 + *
 + *  @langversion 3.0
 + *  @productversion Royale 0.9.3
 + *  @royaleignorecoercion CSSStyleSheet
 +*  @royaleignorecoercion HTMLStyleElement
 + */
 +

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

ok, but then don't understand that we have code that is not usable by our
own.
I think if that code can't be used, it should be as well in Royale-extras
libs, so people wanting to use should grab both the modified closure
compiler and the library with code that uses it

make this sense?

Thanks

2018-06-04 11:10 GMT+02:00 Harbs :

> FYI, this requires changes to the externs committed here:
> https://github.com/royale-extras/closure-compiler/commit/
> 323c6b5f37973fac2bd611bfeb6f80359e3bbc98  extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98>
>
> > On Jun 4, 2018, at 12:04 PM, Carlos Rovira 
> wrote:
> >
> > Great! This seems to be very useful!
> >
> > thanks! :)
> >
> > 2018-06-04 10:22 GMT+02:00 :
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> harbs pushed a commit to branch develop
> >> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/develop by this push:
> >> new 50ca711  Added utility function to dynamically add CSS selectors
> >> 50ca711 is described below
> >>
> >> commit 50ca711de856475536ea26934023ccb2ebdfc360
> >> Author: Harbs 
> >> AuthorDate: Mon Jun 4 11:22:53 2018 +0300
> >>
> >>Added utility function to dynamically add CSS selectors
> >>
> >>I’m not sure if there’s a good way to do this for swf.
> >> ---
> >> .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
> >> .../apache/royale/utils/css/addDynamicSelector.as  | 57
> >> ++
> >> 2 files changed, 59 insertions(+)
> >>
> >> diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
> >> b/frameworks/projects/Core/src/main/royale/CoreClasses.as
> >> index a0a0b58..ee14d3a 100644
> >> --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
> >> +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
> >> @@ -303,6 +303,8 @@ internal class CoreClasses
> >>import org.apache.royale.utils.date.addSeconds; addSeconds;
> >>import org.apache.royale.utils.date.addYears; addYears;
> >>
> >> +   import org.apache.royale.utils.css.addDynamicSelector;
> >> addDynamicSelector;
> >> +
> >> import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
> >> import org.apache.royale.utils.ClassSelectorList;
> ClassSelectorList;
> >> }
> >> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
> >> royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
> >> src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
> >> new file mode 100644
> >> index 000..b7e495a
> >> --- /dev/null
> >> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
> >> royale/utils/css/addDynamicSelector.as
> >> @@ -0,0 +1,57 @@
> >> +///
> >> /
> >> +//
> >> +//  Licensed to the Apache Software Foundation (ASF) under one or more
> >> +//  contributor license agreements.  See the NOTICE file distributed
> with
> >> +//  this work for additional information regarding copyright ownership.
> >> +//  The ASF licenses this file to You under the Apache License, Version
> >> 2.0
> >> +//  (the "License"); you may not use this file except in compliance
> with
> >> +//  the License.  You may obtain a copy of the License at
> >> +//
> >> +//  http://www.apache.org/licenses/LICENSE-2.0
> >> +//
> >> +//  Unless required by applicable law or agreed to in writing, software
> >> +//  distributed under the License is distributed on an "AS IS" BASIS,
> >> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> >> implied.
> >> +//  See the License for the specific language governing permissions and
> >> +//  limitations under the License.
> >> +//
> >> +///
> >> /
> >> +package org.apache.royale.utils.css
> >> +{
> >> +import org.apache.royale.core.IUIBase;
> >> +
> >> +/**
> >> + *  Adds a CSS selector dynamically at runtime.
> >> + *
> >> + *  @param selector The CSS selector.
> >> + *
> >> + *  @param rule The CSS rule to apply.
> >> + *
> >> + *  @langversion 3.0
> >> + *  @productversion Royale 0.9.3
> >> + *  @royaleignorecoercion CSSStyleSheet
> >> +*  @royaleignorecoercion HTMLStyleElement
> >> + */
> >> +public function addDynamicSelector(selector:String,
> rule:String):void
> >> +{
> >> +COMPILE::JS
> >> +{
> >> +var selectorString:String = selector + ' { ' + rule + ' }'
> >> +var element:HTMLStyleElement = document.getElementById("
> royale_dynamic_css")
> >> as HTMLStyleElement;
> >> +if(element)
> >> +{
> >> +var sheet:CSSStyleSheet = element.sheet as
> CSSStyleSheet;
> >> +sheet.insertRule(selectorString);
> >> +}
> >> +else
> >> +

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

FYI, this requires changes to the externs committed here:
https://github.com/royale-extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98
 


> On Jun 4, 2018, at 12:04 PM, Carlos Rovira  wrote:
> 
> Great! This seems to be very useful!
> 
> thanks! :)
> 
> 2018-06-04 10:22 GMT+02:00 :
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> harbs pushed a commit to branch develop
>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>> 
>> 
>> The following commit(s) were added to refs/heads/develop by this push:
>> new 50ca711  Added utility function to dynamically add CSS selectors
>> 50ca711 is described below
>> 
>> commit 50ca711de856475536ea26934023ccb2ebdfc360
>> Author: Harbs 
>> AuthorDate: Mon Jun 4 11:22:53 2018 +0300
>> 
>>Added utility function to dynamically add CSS selectors
>> 
>>I’m not sure if there’s a good way to do this for swf.
>> ---
>> .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
>> .../apache/royale/utils/css/addDynamicSelector.as  | 57
>> ++
>> 2 files changed, 59 insertions(+)
>> 
>> diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> index a0a0b58..ee14d3a 100644
>> --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> @@ -303,6 +303,8 @@ internal class CoreClasses
>>import org.apache.royale.utils.date.addSeconds; addSeconds;
>>import org.apache.royale.utils.date.addYears; addYears;
>> 
>> +   import org.apache.royale.utils.css.addDynamicSelector;
>> addDynamicSelector;
>> +
>> import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
>> import org.apache.royale.utils.ClassSelectorList; ClassSelectorList;
>> }
>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
>> src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
>> new file mode 100644
>> index 000..b7e495a
>> --- /dev/null
>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/css/addDynamicSelector.as
>> @@ -0,0 +1,57 @@
>> +///
>> /
>> +//
>> +//  Licensed to the Apache Software Foundation (ASF) under one or more
>> +//  contributor license agreements.  See the NOTICE file distributed with
>> +//  this work for additional information regarding copyright ownership.
>> +//  The ASF licenses this file to You under the Apache License, Version
>> 2.0
>> +//  (the "License"); you may not use this file except in compliance with
>> +//  the License.  You may obtain a copy of the License at
>> +//
>> +//  http://www.apache.org/licenses/LICENSE-2.0
>> +//
>> +//  Unless required by applicable law or agreed to in writing, software
>> +//  distributed under the License is distributed on an "AS IS" BASIS,
>> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> +//  See the License for the specific language governing permissions and
>> +//  limitations under the License.
>> +//
>> +///
>> /
>> +package org.apache.royale.utils.css
>> +{
>> +import org.apache.royale.core.IUIBase;
>> +
>> +/**
>> + *  Adds a CSS selector dynamically at runtime.
>> + *
>> + *  @param selector The CSS selector.
>> + *
>> + *  @param rule The CSS rule to apply.
>> + *
>> + *  @langversion 3.0
>> + *  @productversion Royale 0.9.3
>> + *  @royaleignorecoercion CSSStyleSheet
>> +*  @royaleignorecoercion HTMLStyleElement
>> + */
>> +public function addDynamicSelector(selector:String, rule:String):void
>> +{
>> +COMPILE::JS
>> +{
>> +var selectorString:String = selector + ' { ' + rule + ' }'
>> +var element:HTMLStyleElement = 
>> document.getElementById("royale_dynamic_css")
>> as HTMLStyleElement;
>> +if(element)
>> +{
>> +var sheet:CSSStyleSheet = element.sheet as CSSStyleSheet;
>> +sheet.insertRule(selectorString);
>> +}
>> +else
>> +{
>> +   var style:HTMLStyleElement =
>> document.createElement('style') as HTMLStyleElement;
>> +   style.type = 'text/css';
>> +style.id = "royale_dynamic_css";
>> +   style.innerHTML = selectorString;
>> +   document.getElementsByTagName(
>> 'head')[0].appendChild(style);
>> +}
>> +}
>> +}
>> +
>> +}
>> 
>> --
>> To stop receiving notification emails like this one, please contact
>>

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

Great! This seems to be very useful!

thanks! :)

2018-06-04 10:22 GMT+02:00 :

> This is an automated email from the ASF dual-hosted git repository.
>
> harbs pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 50ca711  Added utility function to dynamically add CSS selectors
> 50ca711 is described below
>
> commit 50ca711de856475536ea26934023ccb2ebdfc360
> Author: Harbs 
> AuthorDate: Mon Jun 4 11:22:53 2018 +0300
>
> Added utility function to dynamically add CSS selectors
>
> I’m not sure if there’s a good way to do this for swf.
> ---
>  .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
>  .../apache/royale/utils/css/addDynamicSelector.as  | 57
> ++
>  2 files changed, 59 insertions(+)
>
> diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
> b/frameworks/projects/Core/src/main/royale/CoreClasses.as
> index a0a0b58..ee14d3a 100644
> --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
> +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
> @@ -303,6 +303,8 @@ internal class CoreClasses
> import org.apache.royale.utils.date.addSeconds; addSeconds;
> import org.apache.royale.utils.date.addYears; addYears;
>
> +   import org.apache.royale.utils.css.addDynamicSelector;
> addDynamicSelector;
> +
>  import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
>  import org.apache.royale.utils.ClassSelectorList; ClassSelectorList;
>  }
> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
> royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
> src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
> new file mode 100644
> index 000..b7e495a
> --- /dev/null
> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
> royale/utils/css/addDynamicSelector.as
> @@ -0,0 +1,57 @@
> +///
> /
> +//
> +//  Licensed to the Apache Software Foundation (ASF) under one or more
> +//  contributor license agreements.  See the NOTICE file distributed with
> +//  this work for additional information regarding copyright ownership.
> +//  The ASF licenses this file to You under the Apache License, Version
> 2.0
> +//  (the "License"); you may not use this file except in compliance with
> +//  the License.  You may obtain a copy of the License at
> +//
> +//  http://www.apache.org/licenses/LICENSE-2.0
> +//
> +//  Unless required by applicable law or agreed to in writing, software
> +//  distributed under the License is distributed on an "AS IS" BASIS,
> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> +//  See the License for the specific language governing permissions and
> +//  limitations under the License.
> +//
> +///
> /
> +package org.apache.royale.utils.css
> +{
> +import org.apache.royale.core.IUIBase;
> +
> +/**
> + *  Adds a CSS selector dynamically at runtime.
> + *
> + *  @param selector The CSS selector.
> + *
> + *  @param rule The CSS rule to apply.
> + *
> + *  @langversion 3.0
> + *  @productversion Royale 0.9.3
> + *  @royaleignorecoercion CSSStyleSheet
> +*  @royaleignorecoercion HTMLStyleElement
> + */
> +public function addDynamicSelector(selector:String, rule:String):void
> +{
> +COMPILE::JS
> +{
> +var selectorString:String = selector + ' { ' + rule + ' }'
> +var element:HTMLStyleElement = 
> document.getElementById("royale_dynamic_css")
> as HTMLStyleElement;
> +if(element)
> +{
> +var sheet:CSSStyleSheet = element.sheet as CSSStyleSheet;
> +sheet.insertRule(selectorString);
> +}
> +else
> +{
> +   var style:HTMLStyleElement =
> document.createElement('style') as HTMLStyleElement;
> +   style.type = 'text/css';
> +style.id = "royale_dynamic_css";
> +   style.innerHTML = selectorString;
> +   document.getElementsByTagName(
> 'head')[0].appendChild(style);
> +}
> +}
> +}
> +
> +}
>
> --
> To stop receiving notification emails like this one, please contact
> ha...@apache.org.
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Incorrect descendent CSS output

The following CSS:

TitleBar CloseButton
{
width: 16px;
height: 16px;
margin: 0px;
}

is output as:

.TitleBar CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

Instead of:

.TitleBar .CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

I think this is a bug.

Harbs

Re: [royale-asjs] branch develop updated: Removed unselectable selector

It does add the style to the class list.

The only question is how to add the selector to the CSS.

Thanks,
Harbs

> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I think as Alex that better way for this is the bead add the css style to
> classList.
> 
> thanks
> 
> 2018-06-04 6:33 GMT+02:00 Alex Harui :
> 
>> IMO, the better fix would be to just rename the selector in defaults.css
>> to be UnselectableElementBead and have UnselectableElementBead add
>> "UnselectableElementBead" to the classList.
>> 
>> Or am I not understanding what this does?
>> 
>> -Alex
>> 
>> 
>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>> 
>>What I really wanted to do here was create some self invoking code
>> which was run when the UnselectableElementBead class was loaded.
>> 
>>Is there any way of doing that without writing a static method and
>> invoking that?
>> 
>>Thanks,
>>Harbs
>> 
>> 
>>> On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-
>> asjs.git=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>> Kj3OwfvmWh%2Bzk%3D=0
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/develop by this
>> push:
>>>new b157ecf  Removed unselectable selector
>>> b157ecf is described below
>>> 
>>> commit b157ecff5ea11ff2035e105f266b0925c1970005
>>> Author: Harbs 
>>> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
>>> 
>>>   Removed unselectable selector
>>> ---
>>> .../projects/Basic/src/main/resources/defaults.css |  9 -
>>> .../royale/html/beads/UnselectableElementBead.as   | 22
>> ++
>>> 2 files changed, 22 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>> b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> index ea02120..23a324d 100644
>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> @@ -26,15 +26,6 @@
>>>  box-sizing: border-box;
>>> }
>>> 
>>> -.unselectable
>>> -{
>>> - -moz-user-select: -moz-none;
>>> - -khtml-user-select: none;
>>> - -webkit-user-select: none;
>>> - -o-user-select: none;
>>> - user-select: none;
>>> -}
>>> -
>>> Alert
>>> {
>>>  IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>> VerticalFlexLayout");
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
>> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>>> index 6697472..c80c907 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
>>>  public class UnselectableElementBead implements IBead
>>>  {
>>>  /**
>>> +  * @royaleignorecoercion HTMLStyleElement
>>> +  */
>>> + private static function insertRule():void
>>> + {
>>> + // only do this once...
>>> + if(ruleInserted)
>>> + return;
>>> + ruleInserted = true;
>>> + // Inject a new css selector
>>> + COMPILE::JS
>>> + {
>>> + var style:HTMLStyleElement =
>> document.createElement('style') as HTMLStyleElement;
>>> + style.type = 'text/css';
>>> + style.innerHTML = '.unselectable
>> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select:
>> none;user-select: none;}';
>>> + document.getElementsByTagName(
>> 'head')[0].appendChild(style);
>>> + }
>>> +
>>> + }
>>> + private static var ruleInserted:Boolean;
>>> +
>>> + /**
>>>   *  constructor.
>>>   *
>>>   *  @langversion 3.0
>>> @@ -57,6 +78,7 @@ package org.apache.royale.html.beads
>>>   */
>>>  public function set strand(value:IStrand):void
>>>  {
>>> + insertRule();
>>>  _strand = value;
>>> 
>>>  COMPILE::JS
>>> 
>>> --
>>> To stop receiving notification emails like this one, please contact
>>> ha...@apache.org.
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

2018-06-04 Thread yishayw

Carlos Rovira-2 wrote
> this seems like a bug to be fixed at the core of the component, or the
> layout system.

It could be that data binding is messing it up, and that the data provider
change triggers the layout before the rest of the components can probably
size themselves. I need to look a bit deeper.


Carlos Rovira-2 wrote
> for me I'll prefer to
> discuss in mailing list, since GitHub pages seems more like a reference
> site, more than a discussion place.

Maybe if I changed the title to 'migrating from Flex layouts' it would fit
better in the Wiki. My intent was to share some of the problems I
encountered, explain the Royale (Basic) way of tackling them, and open up
discussion on whether or not the Royale way makes sense.


Carlos Rovira-2 wrote
> important changes to jewel layouts, I want to fix some left things and
> write about it to let you all know what's all about.

Sounds good.


2018-06-03 12:21 GMT+02:00 Yishay Weiss yishayjobs@:

> This could be a good topic to put down here…
>
> https://github.com/apache/royale-asjs/wiki/Layout-Challenges
>
>
> 
> From: Yishay Weiss yishayjobs@
> Sent: Sunday, June 3, 2018 1:18:03 PM
> To: dev@.apache
> Subject: RE: [royale-asjs] branch develop updated: Fixes #258. But is that
> a proper fix?
>
> I’ve seen several instances where the offsetParent hasn’t been set yet
> when layout is run, which messes things up. I solved this here by running
> another layout at a later time but I’m interested to hear others on how
> this should be solved.
>
> From: yishayw@mailto:yishayw@;
> Sent: Sunday, June 3, 2018 1:12 PM
> To: commits@.apachemailto:commits@.apache;
> Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a
> proper fix?
>
> This is an automated email from the ASF dual-hosted git repository.
>
> yishayw pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 37a3a6d  Fixes #258. But is that a proper fix?
> 37a3a6d is described below
>
> commit 37a3a6d5a433d97b654b134f4d354214224172b6
> Author: DESKTOP-RH4S838\Yishay yishayjobs@
> AuthorDate: Sun Jun 3 13:11:31 2018 +0300
>
> Fixes #258. But is that a proper fix?
> ---
>  examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7
> ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> index 8b70a52..f25bfdf 100644
> --- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> +++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> @@ -39,6 +39,11 @@ limitations under the License.
>
>  
>  
>  
>
> @@ -56,7 +61,7 @@ limitations under the License.
>  
>  
>
> -rowHeight="40">
> +rowHeight="40">
>  
>sourceID="applicationModel"
>
> --
> To stop receiving notification emails like this one, please contact
> yishayw@.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira





--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [royale-asjs] branch develop updated: Removed unselectable selector

Hi,

I think as Alex that better way for this is the bead add the css style to
classList.

thanks

2018-06-04 6:33 GMT+02:00 Alex Harui :

> IMO, the better fix would be to just rename the selector in defaults.css
> to be UnselectableElementBead and have UnselectableElementBead add
> "UnselectableElementBead" to the classList.
>
> Or am I not understanding what this does?
>
> -Alex
>
>
> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>
> What I really wanted to do here was create some self invoking code
> which was run when the UnselectableElementBead class was loaded.
>
> Is there any way of doing that without writing a static method and
> invoking that?
>
> Thanks,
> Harbs
>
>
> > On Jun 2, 2018, at 11:39 PM, ha...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > harbs pushed a commit to branch develop
> > in repository https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-
> asjs.git=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
> Kj3OwfvmWh%2Bzk%3D=0
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> push:
> > new b157ecf  Removed unselectable selector
> > b157ecf is described below
> >
> > commit b157ecff5ea11ff2035e105f266b0925c1970005
> > Author: Harbs 
> > AuthorDate: Sat Jun 2 23:39:28 2018 +0300
> >
> >Removed unselectable selector
> > ---
> > .../projects/Basic/src/main/resources/defaults.css |  9 -
> > .../royale/html/beads/UnselectableElementBead.as   | 22
> ++
> > 2 files changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
> b/frameworks/projects/Basic/src/main/resources/defaults.css
> > index ea02120..23a324d 100644
> > --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> > +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> > @@ -26,15 +26,6 @@
> >   box-sizing: border-box;
> > }
> >
> > -.unselectable
> > -{
> > - -moz-user-select: -moz-none;
> > - -khtml-user-select: none;
> > - -webkit-user-select: none;
> > - -o-user-select: none;
> > - user-select: none;
> > -}
> > -
> > Alert
> > {
> >   IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
> VerticalFlexLayout");
> > diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> > index 6697472..c80c907 100644
> > --- a/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/html/beads/UnselectableElementBead.as
> > +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/html/beads/UnselectableElementBead.as
> > @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
> >   public class UnselectableElementBead implements IBead
> >   {
> >   /**
> > +  * @royaleignorecoercion HTMLStyleElement
> > +  */
> > + private static function insertRule():void
> > + {
> > + // only do this once...
> > + if(ruleInserted)
> > + return;
> > + ruleInserted = true;
> > + // Inject a new css selector
> > + COMPILE::JS
> > + {
> > + var style:HTMLStyleElement =
> document.createElement('style') as HTMLStyleElement;
> > + style.type = 'text/css';
> > + style.innerHTML = '.unselectable
> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select:
> none;user-select: none;}';
> > + document.getElementsByTagName(
> 'head')[0].appendChild(style);
> > + }
> > +
> > + }
> > + private static var ruleInserted:Boolean;
> > +
> > + /**
> >*  constructor.
> >*
> >*  @langversion 3.0
> > @@ -57,6 +78,7 @@ package org.apache.royale.html.beads
> >*/
> >   public function set strand(value:IStrand):void
> >   {
> > + insertRule();
> >   _strand = value;
> >
> >   COMPILE::JS
> >
> > --
> > To stop receiving notification emails like this one, please contact
> > ha...@apache.org.
>
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

Hi Yishay,

this seems like a bug to be fixed at the core of the component, or the
layout system.

I was not aware about Layout Challenges page. But for me I'll prefer to
discuss in mailing list, since GitHub pages seems more like a reference
site, more than a discussion place. Said that this weekend I was making
some important changes to jewel layouts, I want to fix some left things and
write about it to let you all know what's all about.

thanks


2018-06-03 12:21 GMT+02:00 Yishay Weiss :

> This could be a good topic to put down here…
>
> https://github.com/apache/royale-asjs/wiki/Layout-Challenges
>
>
> 
> From: Yishay Weiss 
> Sent: Sunday, June 3, 2018 1:18:03 PM
> To: dev@royale.apache.org
> Subject: RE: [royale-asjs] branch develop updated: Fixes #258. But is that
> a proper fix?
>
> I’ve seen several instances where the offsetParent hasn’t been set yet
> when layout is run, which messes things up. I solved this here by running
> another layout at a later time but I’m interested to hear others on how
> this should be solved.
>
> From: yish...@apache.org
> Sent: Sunday, June 3, 2018 1:12 PM
> To: comm...@royale.apache.org
> Subject: [royale-asjs] branch develop updated: Fixes #258. But is that a
> proper fix?
>
> This is an automated email from the ASF dual-hosted git repository.
>
> yishayw pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new 37a3a6d  Fixes #258. But is that a proper fix?
> 37a3a6d is described below
>
> commit 37a3a6d5a433d97b654b134f4d354214224172b6
> Author: DESKTOP-RH4S838\Yishay 
> AuthorDate: Sun Jun 3 13:11:31 2018 +0300
>
> Fixes #258. But is that a proper fix?
> ---
>  examples/royale/TreeExample/src/main/royale/MyInitialView.mxml | 7
> ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> index 8b70a52..f25bfdf 100644
> --- a/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> +++ b/examples/royale/TreeExample/src/main/royale/MyInitialView.mxml
> @@ -39,6 +39,11 @@ limitations under the License.
>
>  
>  
>  
>
> @@ -56,7 +61,7 @@ limitations under the License.
>  
>  
>
> -rowHeight="40">
> +rowHeight="40">
>  
>sourceID="applicationModel"
>
> --
> To stop receiving notification emails like this one, please contact
> yish...@apache.org.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [Discussion] Package change names (was Re: 0.9.3 Release)