This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html Section: http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate Mailing list thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027266.html This has been discussed, but I didn't see a bug (even a WONTFIX one) here for it, so I figured I'd file it. Basically, at least Gecko and WebKit don't implement the "title" parameter of history.pushState and history.replaceState due to complexity issues. Here are the relevant Gecko and WebKit bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=585653 https://bugs.webkit.org/show_bug.cgi?id=43730 It will definitely confuse authors for the rest of time to have a parameter that is documented to do something but in fact does not. (It already confused us in the Bugzilla Project.)
Do you have a concrete suggestion as to what we should do with the title parameter?
(In reply to comment #1) > Do you have a concrete suggestion as to what we should do with the title > parameter? I don't, but I figure as a bug reporter my job is to accurately describe the problem, and that the spec authors would be the people with the broad experience required in order to make judgments about implementation. I can tell you that as an author, I would expect it to adjust document.title and adjust the title that appears in my back/forward history. Or I'd expect a fourth parameter that specifies whether or not document.title should be updated.
> I don't, but I figure as a bug reporter my job is to accurately describe the > problem, and that the spec authors would be the people with the broad > experience required in order to make judgments about implementation. I'm sorry if I came across as terse. I just wanted your input, if you had any. At this point, I don't think we can link the title parameter to document.title. Since the parameter currently does nothing, suddenly causing it to affect the DOM could create bugs in sites. I'm also not sure how to sanely link the title parameter up to document.title. It gets really complicated when you start thinking about what happens when you go back and forward; you need to update document.title on each navigation, but some session history entries need to their saved titles from others... I don't think that pushState updating document.title adds a large amount of convenience for web developers, so the main benefit of mucking around here would be to make the API a little more sane. But at that point, we're not tied to making the second parameter affect the page's title; we could make it do anything!
Oh, that's fine about the terseness, I wasn't offended or anything. :-) (In reply to comment #3) > Since the parameter currently does nothing, suddenly causing it to affect the > DOM could create bugs in sites. True, although it will affect fewer sites if we change it now than it will in the future. > I don't think that pushState updating document.title adds a large amount of > convenience for web developers, Well, it could in very complex situations. Essentially, if authors start doing a lot of pushState that we *want* to affect the title (say, implementing an entire multi-page application), then you're pushing the burden of that document.title complexity onto us instead of into the browser. That is, if somebody does start using this API in a very involved application, the problems you're talking about are going to have to be resolved anyway, and it's going to be even more difficult to resolve them in the application than to resolve them in the browser. (Or even if it's simpler, it's going to be a lot of duplication of effort across web applications.) > so the main benefit of mucking around here > would be to make the API a little more sane. But at that point, we're not tied > to making the second parameter affect the page's title; we could make it do > anything! Oh, that's true too. What would be valuable to do with it otherwise?
> Essentially, if authors start > doing a lot of pushState that we *want* to affect the title (say, implementing > an entire multi-page application), then you're pushing the burden of that > document.title complexity onto us instead of into the browser. I don't agree that this is a burden. In fact, all you would need is the following: -- To push a state entry with a title -- history.pushState({title: 'foo'}, ''); document.title = 'foo'; -- To set document.title -- function onPopState(e) { document.title = e.title; } As far as I can tell, this doesn't become any more complicated as your page becomes more complicated.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I agree that it's unsatisfactory, but it's not clear what we can do. I've left the spec as is, which is to say, claiming that the parameter can be used to affect the back/forward UI. I'm very open to alternatives, especially if they get implemented. If anyone is interested in changing this please just experiment and report back with what works, and I'll update the spec accordingly!
mass-moved component to LC1