On Wed, Mar 6, 2024 at 12:25 PM Noam Rosenthal <nrosent...@chromium.org> wrote:
> > > On Wed, Mar 6, 2024 at 11:10 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Wed, Mar 6, 2024 at 12:04 PM Noam Rosenthal <nrosent...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, Mar 6, 2024 at 10:55 AM Yoav Weiss (@Shopify) < >>> yoavwe...@chromium.org> wrote: >>> >>>> >>>> >>>> On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin <vmp...@chromium.org> >>>> wrote: >>>> >>>>> Contact emailsvmp...@chromium.org, nrosent...@chromium.org >>>>> >>>>> Explainer >>>>> https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id >>>>> >>>> >>>> Thanks for the explainer. It's very useful!! >>>> >>>> The explainer mentions console warnings in case authors included an ID >>>> that wasn't encountered, resulting in waiting for the fill document. >>>> Was this implemented? >>>> >>> >>> It was not, good catch! Opened >>> https://issues.chromium.org/issues/328279707. >>> >>> >>>> Will render blocking also happen in cases where no transition took >>>> place? (e.g. on landing pages) >>>> >>> >>> Correct, this feature is not specific to view transitions. It can be >>> used, for example, as a replacement for the existing practice of loading a >>> hidden page and showing 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) > This is merely a declarative way to achieve something that's already > doable with JS in multiple ways, so A and B in the A/B test would be > identical to users, apart from a slight performance benefit (not > calculating styles until we're render-unblocked). Also this behavior is > achievable today using <script blocking=render>, but that feels hacky. So > in essence this feature is a well-lit path alternative to an existing > achievable behavior, which has the benefit of making cross-document > view-transitions easier to author. > > -- 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/CAOmohSLkiydeZzu__tbeNBYrWKGr1r2o6cogoXCKBAn0TrSReg%40mail.gmail.com.
