[whatwg] AJAX History Concerns

[Brady Eidson]

On Nov 12, 2009, at 11:22 AM, Justin Lebar wrote:

>> "The title [argument to pushState] is purely advisory. User agents might use the title in the user interface."
>> 
>> 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.
> 
> On the one hand, the implementation as it is allows developers some
> control over the history entry title independent of the document
> title, and perhaps that's useful.  On the other hand, most use cases I
> can imagine for setting the history entry title are only useful if it
> persists between back/forwards.

I guess having the history entry and the document.title be different at an exact moment in time may be useful, I just can't think of the use case.  See a few responses below.

> It appears in my testing that if you do pushState("title1");
> document.title="title2" Firefox shows "title2" in both the local and
> global history, so setting document.title appears to subsume most of
> the functionality of pushState's title argument.

I imagine that's how it would probably work in most browsers.  But there's still this quantum of inconsistency before the script first updates document.title.

> We could make the API change document.title and remember that change
> between back/forwards, but I think that would be unnecessarily
> complicated.  After a pushState, you'd get a new document which shares
> all mutable state *except* its title with its sibling.

Where does this new document come from?  The whole point of this API is reusing the same document across back/forward entries.

Also, my goal isn't to make things more complicated, but rather remove complication in the form of inconsitency.  

> Unless there's a compelling use for it, perhaps we should simplify the
> API by getting rid of the title parameter altogether.  One can pretty
> easily update document.title on popStates manually.  But perhaps I'm
> missing something; I recall at one time being convinced that the title
> parameter was important.  :)

After more thought and more input from others, this is what my current thoughts have boiled down to - Is there a compelling reason why the title parameter is here and that we can't just rely on the document's title as it existed at the time that pushState() or replaceState() was called?  A use case someone can think of that isn't possible otherwise?

If not, we should just get rid of it.

> 
>> [Given] A1 - A2 - B1 - *B2* - B3 - C1 - C2
>> 
>>> "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."
>> 
>> In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed.
> 
> I don't think removing the entry from the history implies that we
> clear its state object.

This is another point that is not clear.  I assumed that the remaining entry should not have a state object, since "clearState()" seems to clear all state objects.

One interesting side effect of "clearState()" not actually clearing the state object from the current entry means that once a script has opted in to AJAX history by calling "pushState()" or "replaceState()", they cannot explicitly opt out altogether.  I haven't thought this through entirely and don't know if I care.

> "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 up to the second-to-last entry that references the same
> Document.  The current entry is then set to the one remaining entry
> for the Document."

This makes sense to me, and I would support the text being updated to it.

An interesting edge case would be if there is only one entry for the current document.  Your text is precise enough to account for this, but in other areas of the spec we explicitly call out edge cases like this to make it clear.  Something like:

"If the current entry is the only entry for that Document, then the call to clearState() has no effect."

> Certainly the spec could be clarified, however.  I don't think that
> Marius's reading, here that B1, B2, and B3 would all be removed, is
> completely unsupported by the text.  

Me neither.  But Document B "cutting in line" past Document C is unsupported and I have strong objections to that.  I'd like that to be filtered out in no ambiguous terms!

> That said, we didn't implement clearState when we did
> push/replaceState because it's hard to get right and we don't
> currently have a compelling use case.  There are probably lots of
> things we'd change if we were going to implement it -- for instance,
> why go back to the last entry instead of staying at the current one?
> But that's probably a conversation for another thread.

Since the spec is in last call for comments and we have yet to see a single implementation of this, I'd like to keep focusing on it till we have it worked out...  ;)

~Brady

> 
> -Justin