Hide elements until they are resolved. about framework HOT 8 CLOSED

Seems a neat solution to me, it leaves decision to the application developer. We need to mention this in our doc though :)

from framework.

Hi, great to see you again (:

Nice idea, I will have to change the current custom element polyfill for this, but I plan to move to v1 soon anyways.

Gonna land in the next batch hopefully

from framework.

I have a small issue here: The main reason of FOUC (flash of unstyled content) is that the nx script is loaded after index.html is parsed (async or at the bottom of body). If I add the unresolved rule to the script it won't solve the problem (it will also be loaded after the index.html is parsed). A possible solution would be to load nx in the head or add the unresolved rule by hand I guess.

I personally like to load NX synchronously in the head. A lot of people see this as a bad habit, but in case of a full app (not just a widget), the page would make no sense without NX loaded anyways.

What is your opinion?

from framework.

You are right, following angular docs.

For the best result, the angular.js script must be loaded in the head section of the html document; alternatively, the css rule above must be included in the external stylesheet of the application.

Anyways we should provide the rule and leave the decision to the application developer.

from framework.

Yes, that would be the best. So I will just put your snippet into the docs and into NX too.

I plan to do it when we replace the custom elements polyfill v0 with v1, since :unresolved is replaced by :defined in that spec. We have to wait until the Custom Elements v1 polyfill starts to support type extensions with the v0 -> v1 migration. Than it can be added (:

from framework.

LGTM 👍

from framework.

I looked a bit deeper into this. Polyfilling css pseudo classes (like :defined and :unresolved) seems to be not worth it (complexity and overhead are big). Neither the v0 nor the V1 custom element polyfill supports these selectors. I think we should go the angular way and use a simple cloak attribute instead. The drawback is that developers would have to manually add the cloak attribute to the component that causes FOUC instead of relying the custom element registration process in the background. (<my-element cloak> instead of <my-element>).

Hopefully this won't be needed frequently. If the render middleware is used to add content to the component FOUC is usually not an issue.

Thoughts?

from framework.

Otherwise it is a pretty small change and it will get into the alpha.5.1.0

from framework.