Add "Supporting BFCached Documents" standalone guide

[rakina]

See w3ctag/design-reviews#628 (comment) for context.
cc @cynthia @torgo @smaug---- @annevk @domenic

[rakina]

Post-holiday ping :) I've just updated the README now as requested. The guide can already be read at https://w3ctag.github.io/bfcache-guide/ but I made this PR in case there are some suggestions from TAG/other reviewers.

[annevk]

I'm missing some guidance around "in parallel".

At least abstractly it seems that whenever you do "in parallel" followed by "queue a global task" there's an opportunity for a document to become inactive.

However, HTML will block task processing in that case until the document is active again so you can't really know.

I'm also vaguely reminded of an issue around promises here.

E.g., if we consider https://storage.spec.whatwg.org/#dom-storagemanager-persisted. Should that just work as-is or will any changes be needed?

[annevk]

This is pretty poor example in that there's no explicit hook tying this to some algorithm that runs when the fully active state changes. Are there hooks for that?

[rakina]

Unfortunately we don't have hooks for "fully active" state changes. Maybe we should add that? Do you know what's the best way to do that?

[annevk]

I suspect we want something similar to HTML's "update the rendering" where specifications have an algorithm that HTML ends up invoking when it changes the state.

[atanassov]

These are all valid points though not necessarily strong enough to hold back the forking of this document. My suggestion is to open separate issues against the newly forked BFCache document.

[annevk]

I find that a bit rude. I was asked for feedback here and only now you're telling me I should have been filing issues instead.

[rakina]

Hi @atanassov, I think the merge of this PR wasn't urgently needed. The HTML file of the bikeshed file is already part of the gh-pages branch so the document was already accessible from https://w3ctag.github.io/bfcache-guide/. I had intended to merge the reviewed version of the document to that branch after all the issues are resolved and this got LGTMs from other browsers.

@annevk, I'm very sorry for the delay in addressing the reviews here and the sudden merge, I assure you that I will address the issues and update the guide. I have filed an issue for the "in parallel" one, and another issue for the "fully active" state change listener. Thanks a lot for reviewing this PR and all the help!!

[annevk]

(Also, thanks for pushing this! It's great that we give this some more attention.)

[rakina]

Thanks for the review!

I'm missing some guidance around "in parallel".

At least abstractly it seems that whenever you do "in parallel" followed by "queue a global task" there's an opportunity for a document to become inactive.

However, HTML will block task processing in that case until the document is active again so you can't really know.

I'm also vaguely reminded of an issue around promises here.

E.g., if we consider https://storage.spec.whatwg.org/#dom-storagemanager-persisted. Should that just work as-is or will any changes be needed?

Yes, I think tasks that are posted might not actually be run until the document becomes active again (or if the document gets evicted, never run at all). Maybe we can add a section that mentions this explicitly just so that people are aware that this is possible? They will not run when the document is inactive, so hopefully there's no problems with things thinking it's an inactive document in a posted task? (I'm not really sure what the problem might be in your example)

[annevk]

Maybe the better example would be the persist() method in the same document. It's rather unclear whether or not the state ends up changing or the user gets prompted (or is still prompted when going back if they had not answered yet) depending on when the fully active transition happens. I mean, there is a certainly a way to read it that answers these questions, kinda, but I doubt it's accurate.