Description
We discussed this briefly at TPAC last year (and I know there have been a few proposals to address the larger problem at a platform level), but I wanted to open an issue anyway as a reminder so it doesn't get overlooked, and also to solicit feedback from the larger development community.
At the moment, it's a bit tricky for web developers to use the CSS Custom Layout API in a way that doesn't lead to a flash of un/miss-styled content (FOUC). And this is especially import for a layout API because swapping from a fallback is likely to lead to really bad UX (which isn't necessarily true for something like custom paint).
Some current options are:
- Wait for all
CSS.layoutWorklet.addModule()calls to resolve and then add a class to the<body>when ready. - Wrap your CSS in an
@supportsrule and hide things until support is detected - Use hacks to inline the
registerLayout()code (since IIUC there's not yet a way to load this outside of a worklet)
While these are OK solution, there's not particularly ergonomic, and I can see some developers avoiding custom layout entirely because it doesn't just work (i.e. doesn't just work like CSS).
At TPAC @bfgeek mentioned that he plans to support inlining the worklet code, and said there was some discussion of a document-level promise that the rendering engine could await before styling. These all seem like fantastic solutions, but I wanted to open this issue to see if anyone has any other ideas that may make this even easier.