appendChild()复选框:记住使用浏览器后退按钮的选择

Question

提前感谢任何试图帮助我的人.

我有一个表单,我将复选框添加到via appendChild()- 作为用户选择的选项 - 基于一系列标准.

当用户选中这些框中的任何一个,然后单击"继续"按钮将选择发布到另一个页面 - 然后单击后退按钮 - 用户检查的复选框 - 现在已被浏览器忘记(不再选中).

如果我使用php编写复选框或只是使用静态复选框 - 当用户选中任何这些框,然后单击"继续"按钮将选择发布到另一个页面 - 然后单击后退按钮 - 将记住所选的复选框(仍然检查)

我的问题是:

为什么浏览器忘记了用appendChild()创建复选框时用户所做的选择

但是相同的浏览器会记住用户在使用静态复选框时所做的选择

有什么关于appendChild()不允许相同的浏览器记住选中的选择？

[div id="mydiv"] here is where the checkboxes are going[div]


[script type="text/javascript"]

var newInput = document.createElement("INPUT");
newInput.id = "mycheckboxid";
newInput.name = "mycheckboxname";
newInput.type = "checkbox";

document.getElementById('mydiv').appendChild(newInput);

[/script]

Answer 1

浏览器可能"忘记"对DOM的动态更改,因为不同的浏览器使用不同的策略来缓存网页.当您点击后退按钮时,想法是浏览器可以显示其缓存副本,而不是从原始Web服务器重新请求该页面.

它可以(至少)两种方式实现这一目标:

1. 浏览器在离开时缓存页面的DOM本身.重新访问(向前或向后)时,动态变化将持续存在.
2. 浏览器仅在加载时缓存页面的原始HTML(在任何动态更改之前).这会导致失去这些动态变化 - 使用appendChild()或innerHTML不记录对DOM的进一步修改.

Note that some browsers additionally keep modified form data, and others do not. If your goal is 99+% compatibility across all browsers, then you have some work to do.

To work around this you need to persist the state somehow. You have a few options:

1. Save data about the modifications to the page to localstorage. Use a key that is generated randomly on first page load and then kept in the page, so that the state changes will only apply to that instance of the page. On page load, if this key already exists, read the change data out and re-apply the changes. Older browsers do not support local storage.

2. 用饼干做先前的事情.我不推荐这个,因为它有扩散cookie的缺点.Cookie会在每个请求中发送和接收(包括ajax请求),因此每次请求都会传输数据.旧的浏览器可以正常使用它.

3. 放弃您的动态更改模型,并通过发布到服务器进行更改.然后,当从浏览器的缓存中提取时,页面将包含修改后的html.你可能不想要这个,但我想我会为了完整性而指出它.

4. 通过幕后的ajax将有关修改的数据保存到服务器.这与实际上对每个更改进行四舍五入不同,就像上一个项目一样.您仍然动态进行更改,但是您向服务器发布了"advisement"文件.然后,在每个页面加载时,从服务器请求任何调整数据.这与第一个建议类似,但您使用远程服务器作为存储.这会在每次页面加载时产生额外的净流量,但流量可以是最小的,因为它就是这样 page. It also makes extra net traffic occur that would not normally be sent (the advisement data). A clever system architecture, however, could use this information to persist a user's unsubmitted form data across computers and over time in a way that could be very handy (lets say your user does 199 out of a 200-question survey and then his power goes out--with this scheme he has a chance of painlessly continuing later exactly where he left off!).

5. Make your Continue button open a new browser window, preserving the original page intact.

6. Make your Continue button post the data without leaving the page, preserving it intact. You could do a simple lightbox-style overlay.

7. If the lightbox-style overlay will not work but you really have to display a new page and don't want it to be in a new window, then redesign your site to work similarly to gmail: where pages change only through javascript, and only through using #hash tags at the end of URLs to control behavior. This can be difficult but there are libraries out there that can accomplish it. (For some browsers one has to resort to polling to see if the hashtag has changed.) The basic idea is that when you click a link that points to the same page but has a tag on it such as <a href="#about">About</a> the browser will initiate a page load event, and will push a new context into the history forward/back stack, but will not actually load a new page. You then parse the updated URL for the hash code (which maps to some kind of command) and carry it out. Through careful choice of the proper hash codes for each link, you can hide and display the appropriate page dynamically through Javascript and it will appear as if the person is navigating around a real web site. The reason you do all this is that, because the page never loads, you not only can maintain state in Javascript, you can maintain your DOM state as well--you simply hide the page that was modified by the user, and when the back event occurs that means to visit that page again, you display it, and it is exactly how the user left it. Advantage: If your site requires Javascript to operate, then you are not taking a risk by using even more Javascript to accomplish it. Disadvantage: Completely changing the architecture of your site is a LOT of work and can be difficult to get working on older browsers. To get started with this see Unique URLs. You might try out the jQuery hashchange plugin. If your web site has wide distribution you will want to be sure to address search engine optimization and web usability issues. You may want to see this SO page on detecting back button hash changes.

8. Use the same strategy as in the prior point but instead of doing it with hashtags, use the new HTML5 history.pushState() and history.replaceState() methods--see Mozilla browser history.

If your goal is not 99% compatibility across 99% of the browsers in use, then please let us know what you are aiming at, as there may be a shortcut possible.

Update: added an option #8