website home page banner briefly flashing inline styles as text on page load when prerendering (SSG / MPA)

[thescientist13]

Type of Change

• New Feature Request
• Documentation / Website
• Improvement / Suggestion
• Bug
• Other (please clarify below)

Summary

It appears that after merging #611 I noticed that something's inline Shadow DOM styles are briefly flickering on load 😱
https://user-images.githubusercontent.com/895923/136285238-87fe8ea7-f688-4111-9807-146bba56277e.mov

Details

Does seem to be related to <eve-button> based on the source contents being displayed. It is currently being used in the banner component.

I don't recall seeing it before in that branch, so a few things to try

• commenting out <eve-button> (mainly just validate root cause)
• check in development mode
• removing Lit's polyfills-support.js
• investigate he generated HTML for anything obvious
• working backwards in the commit history of upgrade website to lit@2 #611

Wonder if it's a <slot> / Light DOM thing? I don't see it happening anywhere else on the site though... maybe because everything else has data-gwd-opt="static"?

[thescientist13]

Yeah, did some more investigating and it seems related to usage of <style> tags within a render function.

For example. if I do this for the header, eg.

import { css, html, LitElement, unsafeCSS } from 'lit';
import headerCss from './header.css?type=css';

class HeaderComponent extends LitElement {
  .
  .
  .

  render() {
    const { navigation } = this;
    return html`
      <style>
        ${headerCss}
      </style>
      <header class="header">
        ...
      </header>
    `;
  }
}

customElements.define('app-header', HeaderComponent);

The same thing happens as on the home page

---

The thing that seems to make it better in all, and is recommended by Lit, is to use static styles, given known limitations with ShadyDOM / ShadyCSS, which I think has to do with <slot>ed content.

import { css, html, LitElement, unsafeCSS } from 'lit';
import headerCss from './header.css?type=css';

class HeaderComponent extends LitElement {
  .
  .
  .
  static get styles() {
     return css`
       ${unsafeCSS(headerCss)}
     `;
  }

  render() {
    const { navigation } = this;
    return html`
      <header class="header">
        ...
      </header>
    `;
  }
}

customElements.define('app-header', HeaderComponent);

[thescientist13]

So while I can't pinpoint exactly why Lit is failing in this way, from reading I was able to do from the links in my previous comment, in certain scenarios, depending on the level of nesting of ShadowDOM, ShadyDOM might fall apart when using this variant of Lit and combined with using expressions?

import someCss from './some.css';

.
.

  render() {
    return html`
      <style>
        ${someCss}
      </style>
      
      ...  
  `;
}

It seems that doing this is fine though

import someCss from './some.css';

.
.

  render() {
    return html`
      <style>
       :host {
         p {
           color: red;
         }
       }
      </style>
      
      ...  
  `;
}

However, using Lit's styles getter does yield consistent results all the time and from the docs intends to be the idiomatic API to use. My guess is that this would even be further reinforced when we introduce #708 and provide idiomatic SSR support for Lit, instead of just what puppeteer can handle. My guess is Lit user's would be better off using the plugin we create for Lit+SSR.

get styles() {
  return css`
    ${unsafeCSS(eveButtonCss)}
  `;
}

I am happy if puppeteer at least supports the standard HTMLElement approach, even if that means we need to implement our own #548 , since I really don't want to get into the business of supporting every WC libraries's SSR implementation, but just that we can provide an adapter for them, I think is a good balance, IMO.

---

Will open a PR to vendor a hot fix for now just to fix up the home page, and will dig more into this during our next Project, which coincidentally will be focused on SSR. 🤞

[thescientist13]

Not sure if this release from lit-html would help with anything here?

[thescientist13]

closing this out for now but will keep around for tracking as part of the SSR related work.