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

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');"?

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

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.

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

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 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.  By analogy, none of us
would argue that we should couple setting document.title with clicking
links and setting document.location.

-Justin

Received on Monday, 23 November 2009 17:44:55 UTC