Before HTML5 was supported by web browsers, dynamic pages created with multiple Ajax framework requests didn’t use the browser’s history engine. As a result for the user, clicking the browser’s “back” button didn’t point the browser to a previous state of the Ajax-enabled site, and went back to the previous full website that was visited. Before Ajax programming was introduced a way to circumvent that was to use invisible iframes to cause changes in the browser’s history. The way the Ajax framework does this is by changing the URL fragment identifier when a page with Ajax script in it is accessed and monitors it for changes. HTML5 changed that by providing an API standard for communicating with the browser’s history engine. Dynamic website updates also make “remembering” and returning to a previous state of the application harder. There are solutions to this problem and many of them also use the URL fragment identifier. The solution provided by HTML5 for this problem also applies here. Depending on what kind is the Ajax programming application, dynamic page refreshing may collide with user input, more so if using an unstable Internet connection. For example, typing in a search field may send a query to the server for search completions, but the user may not expect that the suggestion box will appear, and if the Internet connection isn’t quite fast, the suggestion list may appear too late when the user has engaged in another activity.