- From: Majid Valipour <majidvp@chromium.org>
- Date: Wed, 20 May 2015 15:00:34 +0000
- To: Majid Valipour <majidvp@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Olli Pettay <Olli@pettay.fi>
- Cc: WHATWG <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
Hi all, I wanted to give you an update on the progress. I have implemented this in Chromium in version 44 behind a runtime enabled experimental feature flag <chrome://flags/#enable-experimental-web-platform-features>. Here are the relevant IDL files for the API: - StateOptions.idl <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/StateOptions.idl&q=StateOptions.idl&sq=package:chromium&type=cs> - History.idl <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/History.idl&q=History.idl&sq=package:chromium&type=cs> It will be great if we could make progress on getting a consensus on the API so that we can actually ship this feature. I think we have narrowed it down to two main options: 1- Setting scroll options using history.{push, replace}State. This is what we have implemented in chrome (see IDLs above). history.replaceState(history.state, '','', {scrollRestoration: 'manual'}) 2- Setting scroll options directly on history object. This is what Jonas has proposed. Per our earlier discussions in this thread it should be possible to define the semantics such that we get per-entry control. history.options.scrollRestoration = 'manual' Both are equally powerful with #1 being better for complex situations where different entries may need to have different scroll restoration behaviour and #2 being better for simpler case where the application wants the same scroll restoration for all its entries. As an experiment, I have created a small script <https://gist.github.com/majido/4cbd0b68d742de319aeb#file-scroll-restoration-global-flag-js> that implements #2 on top of #1. Jonas prefers #2. I am partial to #1. Spec editors (Anne, Ian, Simon, Robin): Do you have a preference here? As a side note, I think it is possible to combine both these in a single API. I just don't feel if the benefit is large enough to justify the added complexity. Simply take #1 and remove "readonly" limitation from 'history.options' and make it the effective default options value for the page (with the semantic we discussed earlier). Both pushState and replaceState will continue to take an optional options parameter that can overrides values set in history.options. Regards Majid
Received on Wednesday, 20 May 2015 15:01:07 UTC