/a/chromium.org/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM
We like to implement this or something similar in blink and would be
interested to hear from other vendors. All feedback on proposed design is
welcome. :)
Thanks
Majid Valipour
[1]
http://stackoverflow.com/questions/10742422/prevent
be okay in the bugs and interop department.
You are more optimistic than I. In any case, I strongly recommend against
such redundancy.
On Wed, 15 Apr 2015, Majid Valipour wrote:
Actually URL is optional in current spec and it defaults to current URL.
Why is this suboptimal?
Because
storage makes things simpler but I am not sure about
its implications.
Majid
/ Jonas
On Thu, Apr 23, 2015 at 3:25 PM, Majid Valipour maji...@chromium.org
wrote:
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
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 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
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
Re-sending my response with my member email address to ensure it is
included in the mailing list archive. Sorry about duplication :(.
-- Forwarded message -
From: Majid Valipour maji...@google.com
Date: Wed, Mar 25, 2015 at 8:22 PM
On Wed, Mar 25, 2015 at 4:32 PM Jonas Sicking jo
** 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
so existing websites will continue to behave as before.
Majid
On Tue, Apr 7, 2015 at 1:50 PM Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Majid Valipour maji...@chromium.org writes:
For example a news site may want to always send user to the page top
where
top news
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 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
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 Wed, Aug 12, 2015 at 11:47 PM Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 12, 2015 at 3:31 AM, Olli Pettay o...@pettay.fi wrote:
There are two options to get an interop solution:
Option 1. Change the spec to reverse order, making the workaround
supported
officially.
Does
Does anybody know if there was any specific reasons behind the current
order?
Are the reasons you discovered yourself not sufficient?
They are pretty compelling but was wondering if there is anything I am
missing.
I guess the
question is whether Chrome can still change at this point
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, 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
> A very common abuse is that when pulling the mouse to hit the back
> button because you are not interested in a page, a hover comes up and
> when the hover comes up, the back button no longer works.
Does 'hover' refer to modal dialog e.g., window.alert?
That is the only way I know that you can
18 matches
Mail list logo
