Initial draft of navigate event spec #63
Conversation
This comment has been minimized.
This comment has been minimized.
|
Note to self: I think this needs updates to handle #65 |
It's not specced so don't put it in the IDL and so on
|
OK, I think this is complete. @natechapin mind taking a look? You probably would most enjoy the preview link in the OP, instead of the raw diff. |
|
@natechapin found a bug while implementing: the "Modify the traverse the history by a delta algorithm" patch needs to pass hashChange in same-document cases where the hash differs. |
| for: URL and history update steps | ||
| text: serializedData; url: history.html#uhus-serializeddata | ||
| text: title; url: history.html#uhus-title | ||
| text: isPush; url: history.html#uhus-ispush |
There was a problem hiding this comment.
Semi-related: It seems strange to me that the HTML spec both has isPush and the "history handling behavior". The spec changes proposed here will greatly expand the use of isPush. Can/should we deprecate isPush in favor of the "history handling behavior" as a cleanup step?
There was a problem hiding this comment.
Hmm, I can see both sides. History handling behavior is very tied to the full navigate lifecycle right now (navigate / all the history algorithms). Whereas the URL and history update steps are much smaller scoped. We could reuse history handling (and assert that it's only ever "default" or "replace")... and I guess that's closer to what Chrome does. Hmm.
@natechapin this should hopefully help. (Check out the preview link that should be auto-generated.) It's a bit more complex than your implementation because I want to preserve any pushState() or replaceState() arguments, and it tries to incorporate all the stuff that you're deferring for now.
I don't yet have the monkeypatches that fire the event, so the "fire an event" algorithm might not be quite right. But I think I captured all the inputs. (There are a lot of them... maybe some can be collapsed, once we see the call sites.)Preview | Diff