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
- History.idl

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:

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
that implements #2 on top of #1.

Jonas prefers #2. I am partial to #1. Spec editors (Anne, Ian, Simon,
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.


Reply via email to