[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 5:01 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 13 Nov 2009, Justin Lebar wrote:
> >> On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> > The idea is that the string you would put into the back button or 
> >> > history menu is not the same as the string you would put into the 
> >> > title bar or bookmarks (i.e. not the same as <title>).
> >>
> >> That doesn't seem too unreasonable, but I think it's strange to set 
> >> that title through push/replaceState, since an alternate page title 
> >> is orthogonal to the idea of an AJAX page with state objects.
> >
> > No more so than an alternative URL, surely?
> 
> 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?


> >> It might be confusing to expose this alternate title in the document 
> >> object, but perhaps we could expose it as a property or setter 
> >> function somewhere else.  Then we could persist it properly across 
> >> forward / backs within the same document.
> >
> > It seems like that would just cause everyone to call pushState() and 
> > updateTitle() instead of just calling pushState(), except that then 
> > people would forget to update the title and your history would have a 
> > bunch of silly-looking titles like "Inbox (3)", "Inbox (20)", "Inbox 
> > (4)".
> 
> Well, people are already going to have to call pushState() and then set 
> document.title if they want to update the title at the top of the 
> browser, even if they specify a title in pushState().

Indeed.


> I imagine that most pages aren't going to try to maintain two parallel 
> sets of titles.  For these cases, I think a pushState() function without 
> a title and propagating document.title changes into the history entry 
> makes sense, because this is what those pages already were doing without 
> pushstate.  For those pages which really want to have two titles, it 
> doesn't seem unreasonable to me that they should have to write an extra 
> line of code to explicitly set the history entry's title.

We could make the second argument optional again, but people complained 
when we did that originally, so I am reluctant to do so. (I don't have a 
reference to the relevant thread off-hand, unfortunately.)


> Without this extra setHistoryEntryTitle() function, I think the API
> for updating the history entry title becomes unnecessarily
> complicated.  If you haven't used pushState() or replaceState(), then
> the history entry's title gets updated when you modify document.title.
> But as soon as you call one of those functions, the two titles become
> permanently unlinked, and further updates to the history entry's title
> have to go through replaceState. And if you want to change the
> history entry's title, you now have to save or reconstruct a copy of
> your state object just so you can pass it back to replaceState().

I don't understand the use cases you are imagining where this would be 
that complicated. Why would you change the session history title without 
changing the URL or state object?


> In addition to avoiding this complexity, the updateTitle() function has 
> the advantage that it allows us to call |updateTitle(undefined)| (or 
> something) to re-link the two titles.

I don't understand what you mean by "linking" here.


> I guess the essential question is whether we see the history entry title 
> as being a separate feature from pushState.  If most or all pages will 
> update the history entry title only in response to a pushState or a 
> replaceState that they'd have made anyway, then maybe it makes sense to 
> keep the history entry title there.  But I don't see why the features 
> should be coupled like that.

I don't understand why the session history title would ever be changed 
except for when you're updating where that session history entry will 
lead (which will need changing the URL or the state).


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

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