我写这篇文章是为了记录一个当前的(明显的)错误。
情况: 给定一个 web 应用程序，用户可以在其中查看和排序表格数据(它从 DOM 加载，并可通过 javascript 排序)。他们可以使用复选框和按钮对查看的内容采取行动。
如果您使用后退按钮返回到表格数据页面，则浏览器会填充复选框的状态。这是预期的行为。
并发症: 如果您首先对表格进行排序(使用 javascript 在 DOM 中排序)，然后填写复选框并转到另一个页面，然后使用后退按钮返回，那么浏览器的行为会有所不同。
目前 Chrome (58) 和 Safari (10.1) 以原始(不是 js 排序的)顺序重新加载表单和表格数据，但按照它们被点击的顺序恢复输入(即忽略输入的任何 ID - - 只是它们当时在 DOM 中的顺序) -- 这导致了非常令人惊讶的行为(乍一看表单似乎是你所期望的，但是不同的表单元素已经用不同的数据恢复了)
但是 Firefox (v50.0) 以 js 排序的顺序重新加载表单和表格数据，并且恢复的输入是正确的。
我在 https://timdiggins.github.io/back-button-restore-sorted-inputs/ 中对此进行了更全面的记录。
理想情况下，浏览器会根据输入的 id 而不是它在 DOM 中的顺序来存储它们的输入数据，或者也会缓存 DOM 顺序。
我会自己解决这个问题，但我希望有人能提出更好的建议。
或者在 HTML5 规范中指出表单的 DOM 不应该是可排序的？ (即，Chrome 和 Webkit 是否有可能在此处表现规范)。
最佳答案
我找到了三种解决此问题的方法。两个非常可靠，但每个都失去了功能，还有一个我有两种想法
1) 在初始表单中禁用动态排序(显然)。
2) 禁止使用 autocomplete="off"为所有表单元素保存表单状态(关于每个输入，参见 https://stackoverflow.com/a/2458153/109175 )。对于行为正常的浏览器(如 Firefox)(在我的用例中从未使用过 Firefox)，可以选择跳过此步骤。
3) 我想到的一个选项是确保在保存表单状态时将顺序重置为原始 DOM 顺序。这可能意味着在表单上添加一个提交前处理程序(足够简单)，但为了确保在使用简单链接导航时正确恢复表单 <a> ，这可能意味着在执行链接之前添加回调——这不包括基于 javascript 的导航。
4) 我想到的另一个选择是关注重新排序过程——要么将其从 js 转换为页面重新加载，要么使用 History API 中的 pushState 或 replaceState。
3 和 4 看起来都很聪明，但是(对于我的用例)我倾向于使用 1 或 2 中的一个来处理减少的功能。
关于javascript - 使用后退按钮和 "sortable"表单问题恢复表单状态(Chrome 和 safari 但不是 Firefox)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43865954/