> > >>>> g it using JS at a particular point. It allows a tradeoff between >>>> smoothness and speed, regardless of view transitions. >>>> >>> >>> OK. In this case it might be interesting to think through current >>> use-cases for such initial page hiding (e.g. A/B testing comes to mind) and >>> see how they could be implemented using this and whether this would be a >>> positive change. Did such thinking take place? >>> >>> >> This kind of thinking did take place, though I'm not sure what kind of >> A/B test you had in mind. >> > > I should've been more specific. The use case I had in mind (but haven't > fully thought through) was to avoid anti-flicker snippets > <https://andydavies.me/blog/2020/11/16/the-case-against-anti-flicker-snippets/> > in A/B testing. (e.g. by including a non-existent ID in <link rel=expect> > and then removing the <link> once the appropriate blocking DOM changes were > applied) >
We can add some examples in the explainer, how some of these anti-flicker use-cases can be implemented using <link rel=expect> instead of those scripts, and the benefit. Would this help move this discussion forward? > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbmqqvU3tmF1eiXh4tLroZeQB5B%3DmufJujkkMPsSiROoQ%40mail.gmail.com.
