W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] AJAX History Concerns

From: Marius Gundersen <gundersen@gmail.com>
Date: Thu, 12 Nov 2009 18:24:19 +1100
Message-ID: <45f4181c0911112324l3255becfkd2204087f44247e5@mail.gmail.com>
I'm not exactly sure what you mean in the first case. How is the title
change hidden from the DOM? When you call document.title = "new title", then
the title does change in the DOM and in the UI.

About your second question, I think you misunderstood it. As you said, it
says:
"Then, if the current entry was removed in the previous step, the current
entry must be set to the last entry for that Document object in the session
history."

In other words, the last entry in the session history must now equal what
was the current entry. It's just worded a bit confusingly. A better way of
saying it would be:

"Then, if the current entry was removed in the previous step, the current
entry must now be pushed onto the session history".

Marius Gundersen


On Thu, Nov 12, 2009 at 12:48 PM, Brady Eidson <beidson at apple.com> wrote:

> For reference see section 6.10.2 of the spec.
>
> In getting an implementation for pushState(), replaceState(), and
> clearState() going I've had a few concerns.
>
> pushState() and replaceState():
>
> When pushState() or replaceState() are called with a URL argument, the
> document's current address is changed.  This has a lot of side effects in
> that it is exposed to scripts and the DOM and most modern user agents would
> update their UI to show this.
>
> However, this same section takes care to point out "The title is purely
> advisory. User agents might use the title in the user interface."  Indeed,
> many user agents would show the title of the current page at the top of the
> browser window or tab, in their back/forward list, and possibly in their
> global persistent history.
>
> But unlike the URL which actually changes in the Document object and is
> therefore exposed to the DOM, this "purely advisory" title change is hidden
> from the DOM.  I'm questioning the reasoning behind this distinction and am
> curious if it was intentional or not.
>
> clearState():
>
> The following text describes clearState():
>
> "When this method is invoked, the user agent must remove from the session
> history all the entries from the first state object entry for that Document
> object up to the last entry that references that same Document object, if
> any.
>
> Then, if the current entry was removed in the previous step, the current
> entry must be set to the last entry for that Document object in the session
> history."
>
> Imagine the following scenario:
>
> A document has 5 state entries.
> They each have a different URL as follows:
> http://www.example.com/page.html?1, http://www.example.com/page.html?2,
> http://www.example.com/page.html?3, http://www.example.com/page.html?4,
> and http://www.example.com/page.html?5
> The current entry is the 3rd entry.
> A script calls "clearState()" so these entries are all cleared out,
> including the current entry.
> Since the current entry was removed, the current entry after the
> clearState() call is changed to be the last entry for the Document.
>
> My reading of the spec is that after clearState() returns, the entries 1-4
> will be gone completely, the state object for entry 5 will have been
> cleared, and entry 5 will now be the current entry.
>
> This has the side effect of the URL for the current entry -
> http://www.example.com/page.html?5 - not matching the current URL of the
> document - http://www.example.com/page.html?3
>
> Is my understanding of what the current entry should be correct?
> If not, what am I missing?
> And is the disjoint between the Document's URL and the current entries URL
> correct?
> If not, what am I missing?
>
> Thanks,
> ~Brady
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091112/32e1463d/attachment.htm>
Received on Wednesday, 11 November 2009 23:24:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC