On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal <noam.j.rosent...@gmail.com> wrote:
> > > On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org > wrote: > >> I agree with Domenic that it's great to see this kind of feature, that >> was traditionally unspecified, getting some clearer developer visibility >> and a spec. While there may still be missing pieces, this seems like a good >> start. I'm looking forward to further spec discussions that would hopefully >> lead to convergence and better interop. >> >> On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola <dom...@chromium.org> >> wrote: >> >>> >>> >>> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> wrote: >>> >>>> FWIW, the comment in the HTML spec triage was positive feedback to have >>>> a spec for this. >>>> The current spec proposal clearly is missing still quite a few cases >>>> (is the idea really that one can use BroadcastChannel with prerendered >>>> page? and the webidl annotation behaves rather oddly) >>>> So it is surprising to see this shipping already now. >>>> >>> >>> Thanks for chiming in, Olli! >>> >>> I have a rather different take. As the team's spec mentor, I'm impressed >>> with the spec work the team has done, on taking what most other browsers >>> have treated as a not-to-be-specified user agent UI feature, and turning it >>> into something much more rigorous and developer-friendly. For example: >>> >>> - The careful auditing of all APIs to see how they should behave in >>> prerendering. >>> - Introducing a well-specified Sec-Purpose: prefetch header, instead >>> of the unspecified X-moz: prefetch or X-Purpose: preview headers. >>> - Considering how to handle edge cases such as redirects, 204s, >>> Content-Disposition: attachment, or pages that do client-side navigation >>> while being prerendered. >>> >>> I think there's definitely still work to be done, as we try to move from >>> the current world where every browser does something different into one >>> that's more fully predictable for web developers. But I think this is >>> similar to other features, like bfcache, where for many years the >>> heuristics and rules used were unspecified (e.g. Cache-Control, unload >>> handlers, BroadcastChannel), and then we've started a slow convergence >>> process as browsers start to care more about interoperability. >>> >>> We can definitely tweak things, like Olli's example of BroadcastChannel, >>> over time and as other browsers indicate willingness to converge. >>> >> >> One potential problem with that approach is that sites may grow to rely >> on that existence of e.g. BroadcastChannel and may break when we take that >> away. >> I don't think that's a risk for the current I2S, as developers are not >> aware that the page is being prerendered outside of the page itself, so the >> chances of them trying to communicate with it are low. >> But that can be a risk for the speculation rules based API, which would >> be good to mitigate. >> >>> >>> Re. BroadcastChannel and friends - it's a totally valid point and > there's an open issue about it ( > https://github.com/WICG/nav-speculation/issues/113). I feel that we > should examine these especially as we move from omnibox to > document-initiated prerenering. > Yeah, just to be clear, I agree page-initiated prerendering multiplies the risks significantly and will thus need more work. I expect there will still be some implementation-dependent behavior (e.g., some implementations may discard a prerender if they use a disruptive API, while others might delay the API results). But things like "does BroadcastChannel work at all or not" are critical to nail down for interoperable page-initiated prerendering. -- 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/CAM0wra_sYWF2iuoX9UAofpQQxaxNmO2J1Ui8zCsZi4v0mQ9fEg%40mail.gmail.com.
