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

[Jonathan Cook]

I have not been following this thread closely but have just read a very 
nested reply that seemed to be more about confusion than actual 
questions or answers.

I find that creating an analogy often helps me see things more clearly 
when discussing use cases in the abstract.  If I am reading the thread 
correctly, the following general use case is being posited:

1.  Navigate to page
    a.  Title is URL
    b.  Title is <title> tag contents
2.  Operations are performed which change state, subtly
    a.  Title is modified
3.  Operations are performed which change state, markedly
    a.  Title is modified
4.  State is registered with pushState, and title from 3a is stored in 
history
5.  Operations are performed which change state, subtly
   a.  Title is modified
   b.  persisted title from 4 is updated with title from 5a.
6.  Operations are persisted which change state, markedly
   a.  Title is modified
7.  State is registered with pushState and title from 6a is stored in 
history

The questions raised are with regards to the legitimacy of step 5b, 
updating a previously-persisted history title and with regards to 
confusion about what title attributes are stored where, what title 
attributes are to be used where and so forth.

The analogy I would propose that makes me understand the legitimacy of 
step 5b is that of the "mile marker" (apologies for those already in the 
21th century, using the metric system), and a vehicle's odometer.  As we 
move the browser state machine from the mile 0 marker at step 1 to mile 
1 (marker, history entry) at step 4 and then mile 2 marker at step 7, we 
go through several stages which might be important for the user to be 
able to track with the odometer (title, and perhaps also the history 
entry title), but for which we don't need to set down markers.

If in real world, mile markers were fractional to whatever level anyone 
ever found useful, they would be lines and not points!

I think in a concrete use case, the elements and objects that are not 
registered with the pushState call (forgive me if I misunderstand what 
this call does, I have not looked into the spec for it), MAY be trusted 
to be in the state represented by the updated title(s) when the history 
functionality is used to return to that state via the built-in methods.  
As such and to avoid cluttering the history with a lot of entries, the 
request is to allow for updating titles without pushing a new state object.

When you turn the car around, you're going to pass right by that rock 
you remembered and that you associated with halfway between mile 1 and 
mile 2.  Something like that, analogies aren't always perfect :)

If the entire state of the browser is NOT reset by moving back to a 
history entry set by pushState, then step 5b (update title in history 
entry) could be valid.  If the entire state of the browser IS reset by 
moving back in history, it would seem that step 5b is not valid, because 
there is a definite disconnect between the state and the title.  The 
state would be the state at step 3 whereas the title represents the 
state at step 5.

The assumptions which are being made about elements and objects that are 
outside the realm of pushState might be dangerous in practice.  It looks 
like trying to do something that you already can let the browser do for 
you.  This may be contributing to the confusion about what is intended.

It might make more sense to me to allow the replacement of the previous 
history entry as an option for pushState method.  In the mile marker 
analogy, the request is that there be a way for there to be a GPS-based 
indicator of where you are at in your travels, not necessarily a 
pin-point showing every single place you turned the car.

Again forgive me if this is already part of the spec or under 
consideration as I am working from the text of the threaded email trying 
to untangle the concepts being discussed and have not had an opportunity 
to review this portion of the spec. 

I have no comments about what titles are stored where, what titles are 
used where.  It looks like that question is answered and is really a 
distraction where one ends up saying, "which title are we modifying in 
step 3a?  which one are we modifying at step 4b?  what does the user 
see?  where do they see it" while trying to understand the intended 
purpose of the use case.

HTH.

Regards,
J5