On Thu, 12 Aug 2010, Mihai Parparita wrote:
On Thu, Aug 12, 2010 at 4:56 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Jul 2010, Mihai Parparita wrote:
https://webkit.org/b/42861 has more tests, but briefly, the behavior
in the latest stable versions of these browser is:
- Firefox
On Mon, 7 Jun 2010, Mike Wilson wrote:
Ian Hickson wrote:
Mike Wilson wrote:
the semantic contract is coming closer and closer to that of the
other storage APIs, so I think it would be an advantage to use the
same interface as well.
I don't see the relevance of storage APIs
On Thu, Aug 12, 2010 at 4:56 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Jul 2010, Mihai Parparita wrote:
https://webkit.org/b/42861 has more tests, but briefly, the behavior
in the latest stable versions of these browser is:
- Firefox will not create a session history entry if the
In section 6.10.2:
The pushState(data, title, url) method adds a state object to the
history. perhaps should be ... adds a state object *entry* to the
history.
The replaceState(data, title, url) method updates the current entry
in the history to have a state object. perhaps should be
The
On Fri, 25 Jul 2008, Jonas Sicking wrote:
So to back up. There are a few things that are important to me:
1. The session history (SH) entries created in this way should act
as much like normal SH entries as possible to the user.
I.e. the user doesn't care if clicking what looks like a
On Sun, 03 Aug 2008 22:47:24 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Personally I think keeping the URL is fine. We can never entirely
prevent pages from having bugs. But instead encourage the safe
transitions, and always use safe-looking transitions in examples in the
spec.
FWIW, I
On Sun, 3 Aug 2008, Jonas Sicking wrote:
The problem I have with this is that it increases the number of
possible user-visible behaviours and failure scenarios:
- same Document, script knows how to handle data.
- different Document, script knows how to handle data.
- same URL,
Ian Hickson wrote:
On Tue, 29 Jul 2008, Jonas Sicking wrote:
I'll check with the ECMA Script folks, but this one might be an
alternative to link to:
http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
State that the object passed as 'data' is passed to JSON.parse with the
second
Ian Hickson wrote:
On Fri, 25 Jul 2008, Jonas Sicking wrote:
So what I think we should do is to enforce that 'data' is a JSON
serializable object.
(We need a better term -- and definition -- for this.)
I'll check with the ECMA Script folks, but this one might be an
alternative to link to:
On Tue, 29 Jul 2008, Jonas Sicking wrote:
I'll check with the ECMA Script folks, but this one might be an
alternative to link to:
http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
State that the object passed as 'data' is passed to JSON.parse with the
second argument not
On Fri, 25 Jul 2008, Jonas Sicking wrote:
So what I think we should do is to enforce that 'data' is a JSON
serializable object.
(We need a better term -- and definition -- for this.)
When entering a SH state for which a Document has been destroyed, we
load the URL associated with that SH
Jonas Sicking wrote:
To minimize the difference between when a SH entry is recovered from the
fastback cache, compared to when the document is reparsed, the Location
object should be changed to reflect the new URL whenever pushState is
called with a url. The advantage of changing the Location
Sent: Friday, July 25, 2008 11:45 PM
To: Ian Hickson
Cc: whatwg
Subject: Re: [whatwg] pushState
Ian Hickson wrote:
On Fri, 25 Jul 2008, Jonas Sicking wrote:
What is the purpose of the 'title' argument? Is the idea that the UA
will show that where it usually shows the title of the page? If so
On Fri, 25 Jul 2008, Jonas Sicking wrote:
What is the purpose of the 'title' argument? Is the idea that the UA
will show that where it usually shows the title of the page? If so the
title isn't purely advisory as it should probably affect document.title
as well. This would seem like a
On Fri, 25 Jul 2008, Jonas Sicking wrote:
What is the purpose of the 'title' argument? Is the idea that the UA
will show that where it usually shows the title of the page? If so the
title isn't purely advisory as it should probably affect document.title
as well. This would seem like a
Ian Hickson wrote:
On Fri, 25 Jul 2008, Jonas Sicking wrote:
What is the purpose of the 'title' argument? Is the idea that the UA
will show that where it usually shows the title of the page? If so the
title isn't purely advisory as it should probably affect document.title
as well. This would
On Fri, 25 Jul 2008, Jonas Sicking wrote:
The idea is to use this title in the session history. It's distinct
than the title and document.title because when the session history
might need to say something like Mail - after opening 'compose
mail', Mail - after typing paragraph ending
Hmm.. I'm sort of seeing where the spec was trying to head. However I
think it too poorly supports the browser restart case.
Comments below.
Ian Hickson wrote:
On Fri, 25 Jul 2008, Jonas Sicking wrote:
The idea is to use this title in the session history. It's distinct
than the title and
On Fri, 25 Jul 2008, Jonas Sicking wrote:
FWIW, the title parameter was added in response to requests in
feedback from application authors, who didn't want to change
document.title for this.
Requesting is easy. *Why* did they request this? Still seems like better
UI design to have
So to back up. There are a few things that are important to me:
1. The session history (SH) entries created in this way should act
as much like normal SH entries as possible to the user.
I.e. the user doesn't care if clicking what looks like a link
results in a navigation or a
Pushstate looks great, but with it a new need arises. When the user changes the
path in the locationbar, reload is triggered. It should not, as to match the
behavior of the hash change. Instead, just an event should be dispatched.
Something like hashchanged or popstate event, I'm not sure. Which
21 matches
Mail list logo
