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. -- 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/726d402c-8154-4118-8a59-28da00e55541n%40chromium.org.
