On Mon, Jul 13, 2015 at 5:56 PM, Majid Valipour maji...@google.com wrote:
On Mon, Jul 13, 2015 at 10:55 AM Philip Jägenstedt phil...@opera.com
If the StateOptions interface could be implemented with no internal
reference back to its owning History object it seems pretty harmless,
a mere holder
On Sun, Jul 12, 2015 at 1:51 PM Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
I think we've already made that assumption given that history.state
already relies on this.
Good point. I'm still somewhat skeptical of
On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote:
It is only used as way to group properties (perhaps similar to
ValidityState?) and to keep History interface clean and stack-like. If that
is not valuable enough to introduce a new interface then putting these on
the
On Mon, Jul 13, 2015 at 4:26 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour maji...@chromium.org wrote:
It is only used as way to group properties (perhaps similar to
ValidityState?) and to keep History interface clean and stack-like. If that
is
On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour maji...@chromium.org wrote:
On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking jo...@sicking.cc wrote:
FWIW I still prefer an API like
history.scrollRestoration = 'manual';
The main reason is that it seems to me that pushState/replaceState has
a
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
I think we've already made that assumption given that history.state
already relies on this.
Good point. I'm still somewhat skeptical of introducing new objects
just for the purpose of grouping some properties if they don't
On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote:
Minor bikeshed:
I have put scrollRestoration on history.options instead of directly history
itself in order to use history.options as an
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote:
Minor bikeshed:
I have put scrollRestoration on history.options instead of directly history
itself in order to use history.options as an interface to contain any other
restoration related attributes which have similar
On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking jo...@sicking.cc wrote:
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
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
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
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
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
On Thu, Apr 9, 2015 at 3:05 PM Ian Hickson i...@hixie.ch wrote:
Also, I'd recommend an option name that suggests more strongly that the
author is expected to restore the position themselves, rather than just
that the position shouldn't be restored. For example, calling it something
like
On Tue, Apr 28, 2015 at 3:24 PM Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour maji...@google.com
wrote:
On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking jo...@sicking.cc wrote:
Jumping in at the end here.
As I've said before, I like the general
On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour maji...@google.com wrote:
On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking jo...@sicking.cc wrote:
Jumping in at the end here.
As I've said before, I like the general idea of giving pages more
control over scroll restoration, but I don't think we
Jumping in at the end here.
As I've said before, I like the general idea of giving pages more
control over scroll restoration, but I don't think we should tie this
to pushState()/replaceState()/onscroll.
My proposal is instead that we add an API like
history.restoreScroll = boolean;
This
On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson i...@hixie.ch wrote:
On Sun, 12 Apr 2015, Anne van Kesteren wrote:
On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
I'd strongly recommend against adding new methods. It'll mean we now
have two different ways to do the same
On Sun, 12 Apr 2015, Anne van Kesteren wrote:
On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
I'd strongly recommend against adding new methods. It'll mean we now
have two different ways to do the same thing, which means more bugs,
which means less interoperability, more
I think the original approach of adding a fourth argument is much better.
It's also a better API in general, since the URL should always be given.
If we had a one-argument form with a dictionary, people would consider
not
giving the URL but just disabling scrolling, which is
On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
I'd strongly recommend against adding new methods. It'll mean we now have
two different ways to do the same thing, which means more bugs, which
means less interoperability, more confusing behaviour for authors, more to
document,
Below is the IDL for the proposed changes:
partial interface History {
void pushState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
void replaceState(in any data, in DOMString title, in optional
DOMString
url, in optional
On Thu, 19 Mar 2015, Majid Valipour wrote:
Almost all browsers restore scroll position when a user traverses
history. This behavior works well for document style web sites but it is
often not appropriate for single-page web applications where the page
content may be reconstructed (often
** Re-sending my response with my member email address to ensure it is included
in the mailing list archive. Apologies for duplication.
On Thu, Mar 26, 2015 at 5:16 AM Simon Pieters sim...@opera.com
…
Yeah... also consider navigating back and forth between two different
sites/apps, without
On Thu, Mar 26, 2015 at 11:12 AM Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour maji...@google.com
wrote:
That is fair. Assuming clear documentation helps alleviate potential
confusion I am fine with deprecation route. I suppose the purpose of the
Majid Valipour maji...@chromium.org writes:
For example a news site may want to always send user to the page top where
top news are displayed regardless of where the user was before. This is
currently being achieved by resorting to workarounds such as setting body
size to 100% and using inner
Hi Nils,
I am not advocating for breaking the back button but in fact the opposite.
The idea is to allow single-page applications that are creating new history
entries and for whom the automatic scroll restoration is *broken* (because
the page is being re-creating on popstate event) to be able to
On Wed, 25 Mar 2015 21:31:51 +0100, Jonas Sicking jo...@sicking.cc wrote:
Is this really something we should tie to the pushState/replaceState API?
It seems like websites that lazily add more content as the user scroll
down, like the facebook feed or twitter feed, might not use
On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour maji...@google.com wrote:
My only concern is to make sure that these new methods replace
history.pushState() and history.replaceState() in the spec. Otherwise I feel
the benefits of a cleaner API is not worth the additional confusion of
having
On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour maji...@google.com wrote:
That is fair. Assuming clear documentation helps alleviate potential
confusion I am fine with deprecation route. I suppose the purpose of the
spec is to not only document the current recommended behavior but also
capture
On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour maji...@chromium.org wrote:
partial interface History {
void pushState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
void replaceState(in any data, in DOMString title, in optional DOMString
On 25/03/2015 14:54 , Anne van Kesteren wrote:
The only suggestion I have is that instead of having four-argument
methods we might want to consider introducing two new methods that
take a dictionary. E.g. history.push() and history.replace(). Giving
the page more control over the scroll position
Is this really something we should tie to the pushState/replaceState API?
It seems like websites that lazily add more content as the user scroll
down, like the facebook feed or twitter feed, might not use
pushState/replaceState, but would still like to handle restoring
scroll position themselves.
Ping. Any thoughts from folks familiar with the history API definition?
This proposal resolves a high-profile issue we've received from a number of
major websites. As Majid said, mobile-optimized websites are being forced
to choose between the fullscreen UX users expect from websites on phones
34 matches
Mail list logo
