#628: Back/Forward Cache

Visit on Github.

Opened Apr 30, 2021

Hi TAG!

I'm requesting a TAG review of Back/Forward Cache (BFCache).

We’ve recently looked into how BFCache is specified in the HTML spec and other standards, and noticed some problems with the current state. We’ve identified possible solutions for some of them, but we’re interested in getting TAG’s opinion on how we should approach these problems, especially the ones we don’t really have answers to.

The explainer can be found here. TL;DR:

  • How various APIs/existing concepts interact with BFCache is quite underspecified
  • How BFCache is specified is quite subtle, so it’s hard for API spec authors to specify things correctly
  • User agent implementation varies quite a lot
  • We have concrete proposal to update various docs (Web Platform Design Principles and Security and Privacy Questionnaire) and improve the foundational HTML spec, but there are open questions on more high-level stuff such as “How should we retrofit current APIs” and “Which behavior should be specified and which should be left to user agents’ discretion?”

This is probably different from the usual TAG review request, as we’re not really asking for a review of specific APIs, but instead want to answer more meta questions around the design process and how we should approach specifying things (as mentioned above). Our goal is to improve currently-existing specifications and also ensure new APIs are designed with BFCache support in mind by integrating it into the existing design guidelines (and hopefully TAG reviews can help enforce this).

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: We're hoping to update TAG docs etc sometime in the next 1-2 months
  • The group where the work on this specification is currently being done: WHATWG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
  • Major unresolved issues with or opposition to this specification: (see explainer)
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @rakina

Discussions

Discussed May 1, 2021 (See Github)

Tess looked at this. This broadly consists of three things:

  1. tighten up the existing specification of the bfcache to try to get implemnentations to converge & to make it easier to write WPT tests for it
  2. fix places in specs that don't correctly take bfcache into account (e.g. things that just check for visibility)
  3. update the design principles and the sec & priv questionnaire to give spec authors guidance

Overall it seems like they've done a really good job finding the things that need doing and they're tackling them.

Tess left a comment.

Comment by @hober May 11, 2021 (See Github)

Hi @rakina! I took a look at this during a breakout at our F2F this week.

We’ve recently looked into how BFCache is specified in the HTML spec and other standards, and noticed some problems with the current state. We’ve identified possible solutions for some of them[…]

Thanks for bringing this to our attention! This is really great work.

We (the TAG) would be super happy to review & merge any PRs you'd like to send our way to improve these documents.

but there are open questions on more high-level stuff such as “How should we retrofit current APIs”

I think you're right that there's sometimes a tension when retrofitting between compat and the reasonable desire to have as many pages eligible for the bfcache as possible. I don't think there's an overall answer—gaguing the severity of a compat hit is ultimately an empirical question, as is the question of how many page's eligibility is negatively affected. You need to take things on a case-by-case basis. And it's clear from your explainer that you understand the tradeoffs.

“Which behavior should be specified and which should be left to user agents’ discretion?”

I think this is ultimately pragmatic. All things being equal, it's better to fully specify things, but there are legitimate reasons for User Agents' policies to differ from one another. The best way to determine if a feature's behavior can be specified or left to user agents' discretion is to ask the engineers who work on that feature in each user agent. How feasible would it be for them to change their behavior to match the desired behavior? If it wouldn't be feasible, is there a way to partially specify things, to narrow the interop gap without entirely closing it? What can everyone live with?

Our goal is to improve currently-existing specifications and also ensure new APIs are designed with BFCache support in mind by integrating it into the existing design guidelines (and hopefully TAG reviews can help enforce this).

This is a great goal and I hope you succeed.

Comment by @rakina May 19, 2021 (See Github)

Thanks @hober! We’ve sent PRs to update the documents (1, 2) and will open more spec issues for BFCache, tracked in the BFCache meta-bug.

We will also continue working with owners of current APIs (and start contacting ones we haven’t reached out to yet) to figure out how BFCache fits into their API. We’re grateful that TAG supports our goal, and we hope TAG can help by checking for the "bfcache consideration" bit for future APIs in TAG reviews!

Thanks again!

Discussed Aug 30, 2021 (See Github)
Discussed Sep 20, 2021 (See Github)

Sangwhan: set to proposed closing

Dan: Two PRs, one on s&p questionnaire and one in design principles that landed. I think it should be closed. We need Tess in the room. Plenary?

Sangwhan: I'll take a look before that. Seems like it's not a new proposal, but to define stuff thatw as never defined properly. We don't have much to say in terms of if it's a bad idea - it's already been done, they're just writing it down.

Comment by @cynthia Dec 6, 2021 (See Github)

Closing! (this should have been closed with the last comment, but something happened.)

Comment by @rakina Aug 25, 2022 (See Github)

Hello! During last month's F2F, Chrome's BFCache team met with TAG and discussed how we can improve BFCache-support checking during TAG reviews, as we have noticed some APIs had gone through TAG review but don't support BFCache.

One thing we decided to do is to rewrite the Design Principles guide and Security & Privacy Questionnaire question to be simpler and more explicit, and move the full BFCache guide into a separate document, like the Promise Guide. I've finished rewriting the guide (with lots of input from @domenic, @fergald, and @cynthia) and can be found here:

We're hoping the TAG will reopen this issue to review the rewritten docs (cc @hober and @torgo). We also realized that the docs didn't get reviewed by other browser vendors last time, so tagging @smaug---- and @cdumez (or other BFCache folks from Mozilla/Apple) to review the new documents.

Other ideas that came up during the TAG F2F was:

  • Adding an explicit "BFCache considerations" section to specs, which @domenic is trying out with some new specs we're working on, we'll see if we can get that be a required section for new specs.
  • Improvements to the TAG design review process to be more consistent and follow the latest guidelines. I don't really have much visibility into this, but looking forward to seeing the improvements!
Comment by @rakina Sep 29, 2022 (See Github)

Friendly ping for reviews :) (should this issue be re-opened?) cc @cynthia @hober @torgo