Back/Forward Cache

[rakina]

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).

• Explainer¹ (minimally containing user needs and example code): https://github.com/rakina/bfcache-explainer/blob/main/README.md
• Primary contacts (and their relationship to the specification):
  • Rakina Zata Amni (@rakina), Google
  • Fergal Daly (@fergald), Google
  • Domenic Denicola (@domenic), Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: Back-forward cache meta-bug whatwg/html#5880
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5815270035685376

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

[hober]

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 have concrete proposal to update various docs (Web Platform Design Principles and Security and Privacy Questionnaire)

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.

[rakina]

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!

[cynthia]

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

[rakina]

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:

• Security & Privacy Questionnaire: HTML version, Google Docs version, PR
• Design Principles: HTML version, Google Docs version, PR
• New "Supporting BFCached Documents" doc: HTML version, Google Docs version. Not really sure how to make a PR for this since it's a brand new doc. Any suggestions?

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!

[rakina]

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