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

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.
To modify the history entry's title when residing at a history entry
which was pushState'd to, you have to call replaceState.

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.

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.

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.

>> 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.  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.

-Justin

Received on Monday, 23 November 2009 20:09:37 UTC