Allow body FOUC prevention to be optional

[ebidel]

boot.js sets the opacity of the body to 0 and transitions it to 1 on WebComponentsReady.

This is problematic for a few reasons:

1. Only portions of an app may be using Polymer elements. We're preventing interactions with the page until we've bootstrapped it.
2. The entire page is painted on WebComponentsReady. Painting is expensive.

We should push folks to use :unresolved where it is available.

[sjmiles]

The intent was to make it opt-out so that new users avoid a common FOUC problem, and anybody that wants out can use something like this:

body {
  /* Prevent Polymer from handling FOUC for us */
  opacity: 1.0 !important;
  transition: none !important;
}

[cribbed from ebidel's chromium-dashboard to be meta]

We obviously didn't communicate this properly from the code. I believe we intended to have a class that did the above, but didn't follow through. Thank you for working it out the hard way.

What do you think about opt-in vs. opt-out for FOUC prevention?

[dannyfritz]

I think it would be better to take the FOUC prevention out and just give it as an example use in the documentation for WebComponentsReady.

I looked for a runtime configuration switch when I wanted to disable the FOUC prevention. But, I didn't see it there.

An opt-in configuration switch would be nice:

<script src="platform/platform.js" prevent-fouc></script>

In the meantime, it is nice to see the !important workaround. Although !important always makes me cringe.

[ebidel]

+1 on opt-in. FWIW, Angular has an opt-in
ng-cloakhttp://docs.angularjs.org/api/ng.directive:ngCloak directive
for this.

Two other examples:

• pages in our docs
  http://www.polymer-project.org/getting-started.htmlthat load polymer
  feel slower than pages that don't. It's because the entire page is
  opacity:0 until all the samples are loaded.
• For chromestatus.com, I chose not to make everything an element so I
  could show more of the page to the user at load time. I ended up turning
  off the FOUC prevention on body because it was hijackng the entire page. I
  can image others in this situation (only using 1-2 components on their
  page) but Polymer eats their entire page until it's ready.

On Wed, Aug 14, 2013 at 6:20 AM, dannyfritz [email protected]:

I looked for a runtime configuration switchhttp://www.polymer-project.org/runtime-config.html#configuration-switcheswhen I wanted to disable the FOUC prevention.

I think it should both be a configuration switch and opt-in.
Something like:

<script src="platform/platform.js" fouc></script>

In the meantime, it is nice to see the !important cringe workaround.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/197#issuecomment-22634596
.

[sjmiles]

!important is cringe worthy.

Agreed, but this is a special case IMO. The application itself gets to use the !important hammer.

+1 on opt-in

Vote heard.

But to be fair, your examples don't clearly advocate for opt-in vs. opt-out, to wit:

pages in our docs that load polymer feel slower than pages that don't.

They probably are slower by virtue of loading stuff. There is no inherent delay caused by the FOUC prevention, unless the fade-in duration is simply too long (which it probably is).

For chromestatus.com, I chose not to make everything an element so I could show more of the page to the user at load time

Sure, this is why there is 'opt' at all. The question is, is it better to have newbies faced with FOUC and needing to go learn about it, or better to put the burden on folks that know enough to make choices like above.

[sjmiles]

I think it would be better to take the FOUC prevention out

Vote heard.

[ebidel]

I was saying that the current mechanism uses WebComponentsReady to add the styles to body. If that event fires after all elements are processed, the more stuff you load, the longer it'll take to transition in the app.

We can also use opt-in as a way to advocate :unresolved 👍

[sjmiles]

the more stuff you load, the longer it'll take to transition in the app

Of course, but in apps we make, that is ideally the minimum amount of stuff needed before the app is ready to be visible.

[sorvell]

Addressed via 24b3b3b.