[whatwg] HTML5 History Management

[Sebastian Markbåge]

Jonas,

That is my interpretation too. But I think it's a little unclear whether
that means that the UA should update any Location fields in the UI. I
understand that this may be optional or outside the scope, but I think that
it should still be mentioned.

Now if the UA is suppose to update the Location field, shouldn't push state
URL be subject to same-domain policies? Is that defined clearly?

Otherwise, this can be used during phishing attacks.

Sebastian

On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond <nathan at nathanhammond.com>wrote:

> Hey Jonas et al.:
> Thanks for the reply, forgive my disbelief on Clarification 1. :) If I'm
> completely with you, that is entirely unexpected on my part (and I've read
> this part of the spec a few times). Is this to imply that, no matter what
> the arguments to pushState(), if the path is relative to the current URL
> there will be no request for a new document and no user-agent initiated
> network activity?
>
> This is a behavior I'm fine with and will meet my needs just as well, I was
> simply expecting to have to use the approach from Clarification 2 in order
> to retain my document object. It does however lend itself to some confusion
> when paired with user agents that don't yet support the history portions of
> the spec as they will have to be handled with hash-based addressing while
> those that support pushState() will have more sane URLs--but that is no
> matter in the grand scheme of things.
>
> Also, that would imply that the popstate only fires when you're navigating
> through history. Is that correct?
>
> Thanks!
> Nathan
>
>
> On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
>
>  On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammond<nathan at nathanhammond.com>
>> wrote:
>>
>>> Clarifications
>>> 1. window.history.pushState({}, "Title",
>>> "/path/to/new/file.html?s=newvalue#newhash") replaces the current
>>> document
>>> object with the one specified by the new URL. It then causes the event
>>> popstate to fire immediately after the load event, correct?
>>>
>>
>> No. The above line with change the uri of the existing document to be
>> "http://example.com/path/to/new/file.html?s=newvalue#newhash" (with
>> the part before 'path' obviously depending on where the original page
>> lives).
>>
>> So no network activity takes place and the Document node remains the
>> same. Also no popstate event is fired.
>>
>>  2. window.history.pushState({}, "Title", "#newhash") creates a new
>>> history
>>> state object with the specified data object, the specified title, the
>>> same
>>> document object, and a location object that replaces the existing hash
>>> with
>>> "#newhash", correct?
>>>
>>
>> Yes.
>>
>> / Jonas
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090730/4f5783b6/attachment-0002.htm>