[whatwg] push/replaceState title parameter (was AJAX History Concerns)
ian at hixie.ch
Tue Nov 24 20:03:15 PST 2009
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.
> 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
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
> 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg