On 1/7/20, 10:41 AM, "Carlos Rovira" <[email protected]> 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&data=02%7C01%7Caharui%40adobe.com%7Cbe680796db94415702f908d793a13a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637140192989760630&sdata=9TS0PDQeiFU8dZ4V%2B69ZzrVQFu2x3DrwnJKQvP2iMBI%3D&reserved=0