<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 11, 2009, at 11:24 PM, Marius Gundersen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I'm not exactly sure what you mean in the first case. How is the title change hidden from the DOM? When you call document.title = "new title", then the title does change in the DOM and in the UI.<br></blockquote><div><br></div>Sure, that's my point. You're talking about the DOM API to title, but I'm talking about the new API that says the title you pass in the function calls is "purely advisory."</div><div><br></div><div>So if you do:</div><div><br></div><div>document.title = "Old title";</div><div>replaceState("state object", "New title", "<a href="http://example.com/index.html?2">http://example.com/index.html?2</a>");</div><div>alert(document.title);</div><div><br></div><div>What does the alert show?</div><div><br></div><div>The current back/forward entry would says "New title" in most (all?) modern browsers. But the actual title of the document, as exposed to the DOM, is still "Old title"</div><div><br></div><div>This seems inconsistent and silly.</div><div><br></div><div><blockquote type="cite">About your second question, I think you misunderstood it. As you said, it says:<br>
"Then, if the current entry was removed in the previous step, the
current entry must be set to the last entry for that Document object in
the session history."<br><br>In other words, the last entry in the session history must now equal what was the current entry. It's just worded a bit confusingly. </blockquote><div><br></div><div>I agree it's confusing. I don't see how you're right here, though.</div><div><br></div><div>Imagine the following session history. 3 documents - A, B, and C. Each have more than one entry because they're all using this hawt new API:</div><div><br></div><div>A1 - A2 - B1 - *B2* - B3 - C1 - C2</div><div><br></div><div>In this scenario, B2 is the current entry.</div><div><br></div><div>"When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any."</div><div><br></div><div>So If a script on document B calls "clearState()", then quite clear, entries B1, B2, and B3 will be removed.</div><div><br></div><div>Oh no, the current entry was removed! So, now what is the current entry? This is most certainly where it gets confusing:</div><div><br></div><div>"Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history."</div><div><br></div><div>The Document object in question is B. B1, B2, and B3 were just removed. There is no "last entry for that Document object" because we just removed them all. In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed. Which would leave us the following:</div><div><br></div><div>A1 - A2 - *B3* - C1 - C2</div><div><br></div><div>I'm not saying this is correct, but it's my best following of the described procedure. Your interpretation is that the list should be:</div><div><br></div><div>A1 - A2 - C1 - C2 - B2</div><div><br></div><div>That seems insane to me. We've never given scripts the ability to arbitrarily re-order the back/forward list before, and I don't think we should start now. Even pushState() carefully preserves the ordering of documents A - B - C. </div><div><br></div><div>What you're proposing is that document B can "cut in line" in front of document C's entries in the list. It seems to me that malicious and/or downright rude site developers could abuse this to always keep themselves "on top" of the back/forward list, breaking the UI expectations of what those little left/right arrows mean.</div><div><br></div><br><blockquote type="cite">A better way of saying it would be:<br><br>"Then, if the current entry was removed in the previous step, the current entry must now be pushed onto the session history". <br></blockquote><div><br></div>That wording would be very clear, but I don't think that's at all what the current language is intending. </div><div><br></div><div>Also, if that was the actual intent and wording, I would object (see discussion above).</div><div><br></div><div>~Brady</div><div><br><blockquote type="cite">
<br>Marius Gundersen<br><br><br><div class="gmail_quote">On Thu, Nov 12, 2009 at 12:48 PM, Brady Eidson <span dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; ">
For reference see section 6.10.2 of the spec.<br>
<br>
In getting an implementation for pushState(), replaceState(), and clearState() going I've had a few concerns.<br>
<br>
pushState() and replaceState():<br>
<br>
When pushState() or replaceState() are called with a URL argument, the document's current address is changed. This has a lot of side effects in that it is exposed to scripts and the DOM and most modern user agents would update their UI to show this.<br>
<br>
However, this same section takes care to point out "The title is purely advisory. User agents might use the title in the user interface." Indeed, many user agents would show the title of the current page at the top of the browser window or tab, in their back/forward list, and possibly in their global persistent history.<br>
<br>
But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM. I'm questioning the reasoning behind this distinction and am curious if it was intentional or not.<br>
<br>
clearState():<br>
<br>
The following text describes clearState():<br>
<br>
"When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any.<br>
<br>
Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history."<br>
<br>
Imagine the following scenario:<br>
<br>
A document has 5 state entries.<br>
They each have a different URL as follows: <a href="http://www.example.com/page.html?1" target="_blank">http://www.example.com/page.html?1</a>, <a href="http://www.example.com/page.html?2" target="_blank">http://www.example.com/page.html?2</a>, <a href="http://www.example.com/page.html?3" target="_blank">http://www.example.com/page.html?3</a>, <a href="http://www.example.com/page.html?4" target="_blank">http://www.example.com/page.html?4</a>, and <a href="http://www.example.com/page.html?5" target="_blank">http://www.example.com/page.html?5</a><br>
The current entry is the 3rd entry.<br>
A script calls "clearState()" so these entries are all cleared out, including the current entry.<br>
Since the current entry was removed, the current entry after the clearState() call is changed to be the last entry for the Document.<br>
<br>
My reading of the spec is that after clearState() returns, the entries 1-4 will be gone completely, the state object for entry 5 will have been cleared, and entry 5 will now be the current entry.<br>
<br>
This has the side effect of the URL for the current entry - <a href="http://www.example.com/page.html?5" target="_blank">http://www.example.com/page.html?5</a> - not matching the current URL of the document - <a href="http://www.example.com/page.html?3" target="_blank">http://www.example.com/page.html?3</a><br>
<br>
Is my understanding of what the current entry should be correct?<br>
If not, what am I missing?<br>
And is the disjoint between the Document's URL and the current entries URL correct?<br>
If not, what am I missing?<br>
<br>
Thanks,<br>
<font color="#888888">~Brady<br>
</font></blockquote></div><br>
</blockquote></div><br></body></html>