On 1/7/20, 10:41 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:

    Hi,
    
    About having CSS downloaded twice, I think is a very interesting topic to
    know more info about.
    I understand that for non-conforming CSS royale rules like ClassReference
    is ok, but for normal CSS rules, seems to me a waste of resources, right?
    
    Questions I have about this:
    
    
       - Are we using normal CSS rules in Royale Code? (If not why we load
       again in code and encode all that simple CSS rules that are processed by
       Browsers)
Royale has a ValuesManager.  The various IValuesImpls implement enough CSS to 
get some app to work.  I'm pretty sure nobody has done a full CSS 
implementation yet.

       - Can we separate royale rules (i.e: ClassReference) from normal rules
       and load normal ones via browsers css and royale ones vía JS?
Don't know.  Probably.  But maintaining the list of what to exclude may not be 
worth the effort.

       - Can we reprocess royale css rules again at later time? (When doing
       runtime theme switch, I'm only switching normal standard rules by 
loading a
       normal CSS file, but what If I want to change beads in components or 
other
       things like that? Can I do that? If so how can I load that at runtime and
       process?
Basic doesn't yet have support for runtime loading of CSS (AFAIK).  But folks 
are welcome to add it in a PAYG manner.

       - What means that framework code doesn't need to call
       "getComputedStyles()"? and why should framework do that?
ValuesManager is called ValuesManager on purpose: to not imply that there must 
be a CSS subsystem determining the values.  In fact, some really simple apps 
don't need CSS at all and can use, for example, SimpleValuesImpl.

The code in the framework (and sometimes the application) needs to know default 
values for things.  By separating the defaults from the code that uses it, it 
makes it easier for folks to change it and helps make sure we don't have 
unnecessary dependencies.

I can quickly think of 3 categories of default values.  There might be more:
1) default beads
2) default values that are not CSS-compliant (MX Emulation of 
"horizontalCenter")
3) default values that are CSS-compliant   

In the Royale component lifecycle, a component is instantiated, then some 
properties are assigned, including custom beads, then the component is added to 
a parent where default beads are added.  Values in categories 1 & 2 must be 
encoded somehow.  The browser will barf if we try to put that stuff in a CSS 
file.  Some stuff in Category 3  is never asked for (color), but some stuff is. 
 If you ask for the width or height, we need to check the CSS to see if it has 
been specified there.  getComputedStyle is supposedly expensive, so the current 
implementation in UIBase checks for a locally set style, then tries for 
offsetHeight/Width.   That seems to be working well enough for now.  Subclasses 
can always do something else.

If someone wants to try using getComputedStyle, they should create a branch, 
build some tests, and see if there is a better way.

-Alex



    Thanks
    
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cbe680796db94415702f908d793a13a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637140192989760630&amp;sdata=9TS0PDQeiFU8dZ4V%2B69ZzrVQFu2x3DrwnJKQvP2iMBI%3D&amp;reserved=0
    

Reply via email to