├── LICENSE ├── README.md └── problem.md /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Web History API 2 | 3 | The goal for this repository to summarize major problems with the [Web History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API) and explore different proposals for addressing these problems. 4 | 5 | See the [problem definition](https://github.com/dvoytenko/web-history-api/blob/master/problem.md). 6 | -------------------------------------------------------------------------------- /problem.md: -------------------------------------------------------------------------------- 1 | # The case for the new Web History API 2 | 3 | The widely available [History API](https://html.spec.whatwg.org/multipage/browsers.html#the-history-interface) 4 | is difficult to use even for the most basic use cases. This has become an impediment for custom-built web apps 5 | and shared component libraries. 6 | 7 | There are several key use cases that require use of the History API, such as: 8 | 9 | * Web app router for a single-page application (SPA). A client-side router intercepts navigation, 10 | peformance necessary loading and rendering in the same window, and eventually updates URL in the 11 | address bar and the history stack. 12 | * UI overlaying components such as popups, dialogs, etc. There are usually no meaningful address 13 | bar changes, but overlays still need be cancelable using back button. E.g. it's a bad UX if a user 14 | clicks back button on a fancy date-range picker popup, but instead of closing the popup the browser 15 | navigates back to a previous page. 16 | * The ephemeral `history.state` could be a useful storage for fast reloads from bf-cache. 17 | * An old-fashioned `` fragment navigation. 18 | 19 | However, there are major shortcommings in the existing API, including: 20 | 21 | 1. The `history.state` is unreliable and can disappear from under a web app at any time. 22 | E.g. due to fragment navigation or a push inside an iframe. 23 | 2. The `history.state` doesn’t work like a stack. Typically stack properties would recursively 24 | apply in the new state unless overridden. The `history.state`, instead, fully replaces the state 25 | on navigations. 26 | 3. The `popstate` event makes very little sense: it fires on pop and fragment navigation 27 | (which is a "push"). It's impossible to process intermediate pops after `window.history.go(-2)`, etc. 28 | 4. The history events are not cancelable. Implementing "Are you sure you want to leave without saving" 29 | involves buffering all history changes and re-pushing them back. 30 | 5. Implementing the client-side navigation is too complicated. Web apps end up intercepting global click events 31 | and rolling special APIs to navigate programmatically. 32 | 6. History and navigation have unpredictable synchronous vs asynchronous semantics. 33 | 7. Even in a very carefully crafted web app, an iframe can completely mess up the application's history 34 | stack. 35 | 36 | Due to these shortcomings most of apps routinely monkey-patch history APIs and roll their own 37 | non-standard APIs. 38 | 39 | 40 | ## New History API 41 | 42 | The main principals for the new API should be: 43 | 44 | 1. History should be a stack. The state and events should follow stack model. There should be clear 45 | push and pop events for each state in the history and the new pushes should not completely reset the 46 | history stack. 47 | 2. Synchronous vs asynchronous nature of the API should be clarified. 48 | 3. Ironically, the dependency on history API should be reduced in favor of higher-level APIs. 49 | 50 | The following is the discussion of several use cases and possible approaches. 51 | 52 | ### Client-side navigation 53 | 54 | A typical web app could rely on a router with heavy history patching, manual stack state management, 55 | history event interceptors, global click interceptors, etc. Instead, the navigation use case could be 56 | supported more directly using `window.onnavigate` event. It'd cover all possible ways a web app could 57 | navigate, such as `location.assign`, `location.replace`, `location.href` setter, 58 | `form.submit[method=get]`, etc. 59 | 60 | A typical web app would only need to do the following to support client-side navigation: 61 | 62 | ``` 63 | window.onnavigate = e => { 64 | if (router.matches(e.location)) { 65 | // Stop browser from navigating. 66 | e.preventDefault(); 67 | router.navigate(e.location); 68 | } 69 | }; 70 | ``` 71 | 72 | To navigate, the user code would simply use normal HTML markup, or would call `location.assign()` 73 | in JavaScript. 74 | 75 | That's it. No global listeners needed, no special state management. In fact, the browser's history 76 | is not even manipulated directly here. An added benefit is that `performance` API would be able 77 | to properly measure the performance of client-side navigation, which would have downstream benefits 78 | for tools and performance analytics. 79 | 80 | ### Overlaying UX and back button support 81 | 82 | Overlaying UX includes popups, dialogs, etc. A typical implementation would use `history.pushState` 83 | and monitor `popstate` events. There are many issues with handling `popstate` events. There's no 84 | event that says "this specific history state has been popped". Instead, a `popstate` event references 85 | the new "current" state. 86 | 87 | To address this, any of the following ideas could be considered: 88 | 89 | * The new API could have a new event for all history states that are popped from the history stack. 90 | * The new API could merge the new history state into the existing state, instead of overwriting the 91 | state completely. More on this later. 92 | 93 | There's another annoyance with using history stack for this use case. E.g. a popup could create a new 94 | history state. However, if a web page is reloaded, it'd not typically want to re-open a popup. Thus 95 | this history state is not very useful - it's more of a filler to intercept the back button. The back 96 | button support, in this case, is more comparable to the Esc key handling, which most of such UIs 97 | currently do anyway. In fact, maybe a simpler approach for the new API to allow the history state to 98 | be bound to the Esc key, which will be automatically emited when the state is popped. 99 | 100 | ### Preserving history state 101 | 102 | The `history.state` could be a solid option for many use cases, however, it's currently to unpredictable. 103 | For instance, consider the following snippet: 104 | 105 | ``` 106 | window.history.pushState({a: 1}, '', ''); 107 | 108 | // Now I know my state! 109 | window.history.state.a === 1 110 | 111 | // User navigates to a fragment via 112 | 113 | // Oops. The state is lost. 114 | window.history.state === null 115 | ``` 116 | 117 | Instead of completely overwriting the history state, the merge operation could be used, aka `Object.assign()`. 118 | Thus, the snippet would work differently: 119 | 120 | ``` 121 | window.history.pushState({a: 1}, '', ''); 122 | 123 | // Now I know my state! 124 | window.history.state.a === 1 125 | 126 | window.history.pushState({b: 2}, '', ''); 127 | 128 | // New state: 129 | window.history.state.b === 2 130 | // But the old state is still available: 131 | window.history.state.a === 1 132 | 133 | // User navigates to a fragment via 134 | 135 | // The old state is still there: 136 | window.history.state.a === 1 137 | window.history.state.b === 2 138 | ``` 139 | 140 | ### Vetoable history stack 141 | 142 | A new `beforepopstate` event could be modelled after the [onbeforeunload](https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload). 143 | It wouldn't directly veto history changes, but could instruct the browser show a confirmation prompt. 144 | 145 | --------------------------------------------------------------------------------