[whatwg] push/replaceState title parameter (was AJAX History Concerns)

[Ian Hickson]

On Mon, 23 Nov 2009, Justin Lebar wrote:
> On Mon, Nov 23, 2009 at 6:46 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 23 Nov 2009, Justin Lebar wrote:
> >> I'm not sure I agree.  It seems to me that if you set the page's URL,
> >> it's likely that you'll want to change the state object (if you're not
> >> storing all your data in the URL).  On the other hand, one might want to
> >> change the history entry title without ever changing the URL or the
> >> state object.  In the simple case, consider a page which uses no AJAX at
> >> all, but just wants to display a shorter title in the history than in
> >> the titlebar of the browser.  Does it make sense for this page to call
> >> "history.replaceState(null, 'new title');"?
> >
> > I've never heard anyone asking for this; do you have a concrete example?
> 
> In the absence of push/replaceState, changes to document.title
> propagate to the history entry title -- they're linked together.
> Calling pushState unlinks them in the sense that after the call,
> changes to document.title no longer affect the history entry's title.

This seems to be a bit of an extrapolation from the spec. The spec doesn't 
say what the title should be when the pushState() method hasn't been 
called; that it is linked to the latest state of the <title> element is 
not required by HTML5 as far as I can tell.


> To modify the history entry's title when residing at a history entry 
> which was pushState'd to, you have to call replaceState.

Right.


> Thus you'd need to call history.replaceState(currentStateObject, 
> newTitle) when you changed document.title on a page which was 
> pushState'd to and wanted to reflect that change in the history entry. 
> Suppose Gmail wanted to update the unread messages count in both the 
> history and in document.title.

Why would GMail ever want to update the unread count in the history? That 
would make no sense.


> Honestly, I don't think adding an extra set of titles will be 
> particularly useful, and I imagine that most websites will use just one 
> title for both the history entry and the browser title.  But that's 
> exactly the problem: As soon as you call pushState, you now have to be 
> aware that changes to document.title now no longer affect the history 
> title.

I don't understand under what conditions this would be a bad thing. It 
seems to me that once you're calling pushState(), this is exactly what you 
would want.


> To be clear, my contention is that pushState shouldn't have a title 
> parameter, not that we should have a updateHistoryEntryTitle() function.  
> I'm fine with the idea of the history entry title reflecting the state 
> of document.title immediately before the most recent time we navigated 
> away from that entry, as it does now.  But if we want to allow the 
> titles to be set independently, I don't think pushState is the right 
> mechanism.

I don't think we want titles to be set independently. It doesn't make 
sense to adjust the history title unless you're also adjusting the URL or 
state object, IMHO.


> >> By analogy, none of us would argue that we should couple setting 
> >> document.title with clicking links and setting document.location.
> >
> > Actually, I would; that's exactly what I'm arguing in fact. With 
> > normal navigation, the coupling is done by the UA (first setting the 
> > title to the URL, and then updating it when a <title> element is found 
> > during parsing). With pushState(), the "navigation" is implicit 
> > (scripted) and so the URL and title changes have to be done 
> > explicitly.
> 
> This doesn't suggest that we shouldn't have a updateHistoryEntryTitle() 
> function, just as the existence of <title> doesn't suggest that code for 
> modifying the document's title should be
> 
>     document.navigateTo(document.location, newTitle)
> 
> Adding an updateHistoryEntryTitle() function while leaving the title 
> parameter in pushState might be better than things are now.  But since 
> we have to explicitly set document.title after a pushState anyway, 
> removing the title from pushState doesn't create any more work for the 
> vast majority of use cases.

Why would you have to change the document.title?


> I don't see why we need to add all this complexity to support the edge 
> use case where the history title and document title are different.

I don't think it's an edge case. I think it's likely pretty much the only 
case, or at least the most common case.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'