W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] history.pushState() and replaceState()'s title parameter

From: Justin Lebar <justin.lebar@gmail.com>
Date: Thu, 22 Jul 2010 16:30:22 -0700
Message-ID: <AANLkTimagwsetyBxt8BD2K1zPgwbeHvMpiT6ZWGYZm_c@mail.gmail.com>
Just to follow up on this: We just pushed a change to Firefox to
completely ignore the title parameter, as WebKit does.

We're getting close to locking down Firefox for the next release.  If
we want to do something more creative with the title parameter, now is
the time for action.

-Justin

On Wed, Jun 23, 2010 at 11:15 AM, Justin Lebar <justin.lebar at gmail.com> wrote:
> Safari 5 and Chrome 5 recently shipped the history.pushState and
> replaceState methods. ?Firefox 4 will also include those methods when
> it ships.
>
> pushState and replaceState take three arguments: An opaque data
> object, a title, and an optional URL. ?Currently, Safari and Chrome
> both ignore the title parameter.
>
> Jonas Sicking <jonas at sicking.cc> and I have been talking with Brady
> Eidson <beidson at apple.com> and Darin Fisher <darin at chromium.org>,
> about what we can do to clean up this API, since having an unused
> parameter in our brand-new functions is unfortunate.
>
> Ideally, we might change the pushState and replaceState methods
> themselves, perhaps changing them so they only take a URL and an
> optional data object. ?But since Chrome and Safari have already
> shipped the method, and since we hear that the functions are already
> being used on the web, it's probably too late to add or remove
> arguments from the functions.
>
> It seems that the intent of the spec as it stands is that the title
> parameter should show up in the session history list (shown e.g. when
> you click the down arrow next to the forward button), but not in the
> application's title bar. ?We think this is confusing (as evidence,
> observe that two browsers skipped this step!) and adds a lot of
> complexity for a small amount of gain, so we're not in favor of this
> approach. ?If modifying the document's title in the session history
> list is a desirable feature, then we could expose that property to the
> DOM just as we expose document.title.
>
> Seeing as we're stuck with the title argument in pushState and
> replaceState, we propose that it modify document.title in an intuitive way:
>
> * Before we unload a history entry, we save document.title into the
> history entry.
> * When we activate a history entry, we set document.title to the value
> stored in the history entry.
> * When we pushState, we set document.title to the title parameter
> after activating the new history entry.
> * When we replaceState, we set document.title to the title parameter.
>
> In the last two cases, if the title parameter is empty, we leave
> document.title unchanged.
>
> We think this is a good compromise between complexity and functionality.
>
> -Justin
>
Received on Thursday, 22 July 2010 16:30:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC