You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/01/07 18:41:15 UTC
CSS Downloaded Twice (was Re: Including CSS in apps)
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)
- Can we separate royale rules (i.e: ClassReference) from normal rules
and load normal ones via browsers css and royale ones vía JS?
- 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?
- What means that framework code doesn't need to call
"getComputedStyles()"? and why should framework do that?
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: CSS Downloaded Twice (was Re: Including CSS in apps)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
- 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.
>
My question here was more about the current CSS rules (the same used by
browsers, not particularl royale ones like ClassReference), if we really
need to encode since don't know if that rules are used in royale AS3 code
>
> - 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.
>
In Jewel, I end separating as follows:
- Jewel.SWC: Has only royale CSS rules (beads needed by Jewel
components) and some CSS rules that are mostly structural. For example,
display: flex, position: relative, or z-index: 1 or overflow: auto to name
a few. Those are rules that will be always needed to make a component show
in a determined way. I think this CSS rules should not be part of a themes,
although in some cases could be (very few cases), and in that case people
could override in a theme.
- JewelTheme.SWC: This theme, or any other one based on the same
principles has just real theme rules that can change, for example:
background, border, border-radious, fonts, color, and so on. All these make
a difference in how the components are visualized and I determined that are
the properties that makes sense to make part of a theme.
But I have one case, that I did as an experiment (maybe could change in the
future). I created "gap" that is used by jewel components in layouts. This
one is processed since is a Royale one, something similar to a bead.
> - 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.
For me this will be interesting to make the runtime CSS in Jewel extend to
all Royale capabilities. For now is just for CSS browser rules.
What class-method should I look to try to do this? IOW, where in the royale
basic lifecycle should this be implemented?
Should this be a bead? Any guidance here's welcome to imagine how this
could be
>
>
- 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.
>
That means, that If I switch to SimpleValuesImpl in a Jewel App, I can
avoid to have all CSS browser rules twice?
>
> 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
>
1 and 2 is clear to me. What I don't understand is the need of 3, since
this is done by the browser right?
>
> 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.
>
ok I think I understand now the reasons. Thanks
>
> 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
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: CSS Downloaded Twice (was Re: Including CSS in apps)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/7/20, 10:41 AM, "Carlos Rovira" <ca...@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&data=02%7C01%7Caharui%40adobe.com%7Cbe680796db94415702f908d793a13a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637140192989760630&sdata=9TS0PDQeiFU8dZ4V%2B69ZzrVQFu2x3DrwnJKQvP2iMBI%3D&reserved=0