Can we require no FoUC/jank on initial load?

[eeeps]

All existing experimental prollyfills are susceptible to some form of FoUC/layout jank.

As elements are laid-out, and then queried asynchronously[1], before being, possibly, re-laid-out, re-queried, &etc — it’s hard (though maybe not impossible?) to implement CQs in a way that doesn't take a few paints to settle down.

This is why Shopify abandoned their CQ solution: https://twitter.com/dfmcphee/status/870458614842105856

Personally, container queries taking effect "a frame later or so"2 on window resizes bugs me very little. But jank on the initial load bugs me very much.

Are there reasonable, specific requirements we can set up around FoUC/layout jank?

[1]: for the importance of async querying as an essential part of any CQ solution (and not just an unfortunate characteristic of temporary prolyfills), see https://twitter.com/gregwhitworth/status/850129597844701184

[eeeps]

Related: https://github.com/ausi/cq-prolyfill/issues/39

EDIT Note that this thread invalidates my opening statement. cq-prolyfill.js in the head is FoUC-free (but slower to arrive at a finished page than FoUC-y async or defer).

[eeeps]

So, turns out, "async" doesn't mean what I thought it meant, and this is, I think, a non-issue. See https://twitter.com/etportis/status/872575323757436928. Closing.

[eeeps]

Double-turns-out, even though Canary, which I was testing with, currently runs async microtasks to completion before painting, Firefox won't. So the threat of a FoUC, with async evaluation, is real.

[beep]

Pinging #36 and #60, as this should definitely be captured/addressed in both sections.

[ZeeCoder]

Is this an issue with a native ResizeObserver?

[beep]

Shortly after pinging a bunch of issues I had some coffee, and this probably could land in the Limitations section, huh? (#53) Like,

Known JavaScript-based solutions may incur additional performance penalties, which could impact a user’s experience. (For example, if a prollyfill is loaded as a blocking asset, the overall render time is impacted; if the script is loaded asynchronously, a FoUC may introduce layout jank to the design.

but, like, with Better Words, not those words

[marcoscaceres]

@beep, those words are pretty good. If the FOUC is affecting a library in the wild, even better.

@tomhodgins, has this bitten you at all with the various things you built?

[tomhodgins]

@tomhodgins, has this bitten you at all with the various things you built?

Absolutely :D I've written about one technique I used when building with EQCSS to work around it here: How to avoid FOUC with EQCSS

Basically the idea is…set opacity: 0; in CSS to make the element invisible immediately, then reset the opacity to 1 from a JS-powered style after the relevant JS-powered styles that apply to that element have had a chance to evaluate first. It's not perfect, but it looks alright in the case where you can't force the plugin to load before the HTML markup you are applying styles to.

In general, the principle applies to all forms of JS-powered styling, not just element queries :D

[marcoscaceres]

Awesome! Remember, the goal here is to expose the limitations in the platform. So, documenting the hack, and possible side effects of that hack are important.

In general, the principle applies to all forms of JS-powered styling, not just element queries :D

Noob question wrt Houdini.. they must cope with this somehow, no?

[marcoscaceres]

Ok, so to close this issue, we basically should distill @tomhodgins post down as much as possible, and combine it @beep's words above. We then reference @tomhodgins post it as evidence that it's a problem that people have hit. If we know of other techniques, we should cite those too.