Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Wed, May 20, 2015 at 11:00 AM Majid Valipour maji...@chromium.org
wrote:
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?
Anne, Ian, Simon, Robin,
Do you have a preference one way or another for either of the above APIs?
I have a git repo https://github.com/majido/scroll-restoration-proposal where
I have spec'd the first option
http://majido.github.io/scroll-restoration-proposal/history-based-api.html
(as
implemented in Chromium) and am tracking issues against it. Unless there is
a strong preference against #1, I feel it is reasonable to try to ship it.
Majid
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour maji...@chromium.org wrote: Do you have a preference one way or another for either of the above APIs? Not really. The fact that history and navigation is not really cross-browser makes me a bit wary about extending it further, since we obviously don't really understand the primitives well, but I don't have the bandwidth to tackle that at the moment. -- https://annevankesteren.nl/
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
FWIW I still prefer an API like
history.scrollRestoration = 'manual';
The main reason is that it seems to me that pushState/replaceState has
a largely orthogonal set of use cases that it tries to address from
scroll restoration. So I suspect that grouping the two together will
create awkwardness in the API in the future.
But I don't have time to chase this issue.
/ Jonas
On Mon, Jun 29, 2015 at 8:14 AM, Majid Valipour maji...@chromium.org wrote:
On Wed, May 20, 2015 at 11:00 AM Majid Valipour maji...@chromium.org
wrote:
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 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?
Anne, Ian, Simon, Robin,
Do you have a preference one way or another for either of the above APIs?
I have a git repo where I have spec'd the first option (as implemented in
Chromium) and am tracking issues against it. Unless there is a strong
preference against #1, I feel it is reasonable to try to ship it.
Majid
