HTML5 History API today and without limitations
HTML5 History API Library
Initially, this project was intended to add support for the HTML5 History API in older HTML4 browsers. The first versions of the library were aimed precisely at these needs, but taking into account the past tense and the wishes of respected developers using this library, it has grown to the level that it performs some intermediate actions for adding / correcting the functionality that is described in the interface specifications.
To date, I can safely call the library, in my opinion, fully completed. Of course, I think there will be a mistake in the library’s work, the library has been tested by me in different conditions and browsers, but as you understand, you won’t catch everything, and you will miss something. And so let's get down to the description of the possibilities and subtleties of the library.
Using.
Using the library is very simple, it tries to adhere to the official specification for the History interface.
I will give a small example:
<!DOCTYPE html> <html> <head> <script type="text/javascript" src="history.js"></script> <script type="text/javascript"> window.onload = function() { // DIV function appendText( text ) { var div = document.createElement( "div" ); div.innerHTML = text; document.body.appendChild( div ); } // function handlerAnchors() { // var state = { title: this.getAttribute( "title" ), url: this.getAttribute( "href", 2 ) // 6-7 } // history.pushState( state, state.title, state.url ); // .. // ... appendText( '<b> :</b> ' + '<span style="color: green;">' + state.url + '</span>' ); // return false; } // var anchors = document.getElementsByTagName( 'a' ); // for( var i = 0; i < anchors.length; i++ ) { anchors[ i ].onclick = handlerAnchors; } // popstate // back/forward window.onpopstate = function( e ) { // appendText( '<b> :</b> ' + '<span style="color: green;">' + history.location + '</span>' + '<br/><b>state:</b> <span style="color: green;">' + JSON.stringify( history.state ) + '</span><br/><br/>' ); // .. // ... } } </script> </head> <body> <h1> , back/forward</h1> <a href="/mylink.html" title=" My Link">My Link</a> <a href="/otherlink.html" title=" Other Link">Other Link</a> </body> </html> As you can see, there is nothing difficult in using this library; you probably noticed from the example above that there are practically no differences / differences in the use of the methods described in the specification for the History interface. There is only one small difference in the fact that getting the current link when the
popstate event is popstate , we get from the history.location object.')
How it works.
In HTML5 browsers, it performs only the role of fixing bugs / errors when working with history. And links have a normal nice look, without using any hash-fallback.
In HTML4 browsers, of course, hash-fallback is used, because of course there is no other option for such browsers. But for the developer inside the JavaScript-code it will not be some kind of ailment, because the links will have the appearance that they were originally intended. And you do not need anywhere either to prescribe hash-links and / or follow the rules for search engines, so that they in turn would normally index the site. After all, the links will be of normal appearance, which means that the search robot will quietly follow the necessary link.
Functional library.
The library has small subtleties when working with it. As we have already noted, the library has its own
history.location object, it is no different from the known window.location object. That is, in a word, this is the link to the window.location object, except that in HTML4 browsers it intercepts getters / setters from the original object, makes the necessary modifications and returns the result.The way of working with
history.location is unlimited; you can also assign it, receive it, access its properties, etc.For example, it looks like this:
history.location = "http://yandex.ru/"; // . history.location.hash = "#newhash"; // hash . // , // Location The next subtlety of the library is its customization for your needs. The library does not have any objects for setting, but it receives them from the GET parameter when the library is connected via the HTML
script element, that is, it reads the link when the script is connected to the site.Smooth it like this:
<script type="text/javascript" src="history.js?type=/&redirect=true&basepath=/pathtosite/"></script> By connecting the library to the site, you can specify in advance what actions are required from it. The library has only three parameters, now I will describe to you their actions and necessity.
Parameter: type
Does not play a special role, it is needed to decorate links in HTML4 browsers. In this parameter, you can specify absolutely any string / character that will be added after the # (hash) character, thus you simply decorate the link with the desired character / text. For example, if I set the text to this parameter: “HelloWorld /”, then the links will have this substring. Suppose clicking the link http://somesite.com/folder/page.html we get a link of the form: http://somesite.com/#HelloWorld/folder/page.html . You can experiment with this parameter. By default, this parameter has the substring "/" (forward slash) in the library.
Parameter: basepath
One of the important parameters, it is for this parameter that the library generates a link for the
history.location object. It indicates where the root of the site is located, usually the sites are right in the root of the domain, but sometimes you need to put the site in a different folder from the main domain. For this purpose, this parameter was added, so that sites located outside the root could work fully in HTML4 browsers.Parameter: redirect
This parameter is responsible for site redirection when clicking on a link copied in an HTML4 browser to an HTML5 browser. It simply redirects the user of the following link: http://somesite.com/#/folder/page.html to the link of the form http://somesite.com/folder/page.html and vice versa, if the user followed the link from the browser HTML5 to HTML4 browser. It is important to remember that this parameter is closely related to the basepath parameter, since it is for this parameter that it draws conclusions on where to redirect the user.
Conclusion
In conclusion, I want to add that sometimes sometimes you need to find out which browser we are in, in the HTML4 browser or in the HTML5 browser. For these purposes, I added an emulate property to the
window.history object indicating whether the emulation is window.history or not. If this property is true , then we are in the HTML4 browser and work with hash links, otherwise otherwise.I also add that in HTML5 browsers the library corrects the bugs / deficiencies of the History interface and everything connected with it. For example, in Safari it adds a state object to the History interface, in Safari and Chrome browsers it removes the initial state (
popstate when the document is first loaded).It is important to remember, the library does not do what is not described in the specification, it operates only according to the official document. The library should be connected on the very first page, since it overloads some methods / properties, and it immediately intercepts any calls to methods / properties associated with it. Therefore, it is worth it to connect before other libraries / scripts.
The library works with absolutely any frameworks and does not use them for its own purposes.
The library has been tested in browsers:
IE 6+
FireFox 3+
Opera 11+
Opera Mobile 11+
Chrome 17+
Safari 5+
If you have the opportunity to check in other browsers or versions and you will not be difficult for me to unsubscribe, then I will be very grateful to you.
All wishes, questions, bug reports, etc. You can send me to the mail indicated on the GitHub or write in the Issues section of the GitHub.
You can download and view this library on GitHub: https://github.com/devote/HTML5-History-API
You can also see the library working on my unfortunately unfinished website: http://history.spb-piksel.ru/ . The site itself is not completed, but you can look at the library working capacity.
UPD (09/12/2012): Important! I often began to write / report about the inoperability of the library in IE9. The problem is related to the fact that IE9 is a capricious browser and finds fault with all the details. As it turned out, many developers that use scripts taken from GitHub run into problems with their inoperability, because IE9 expects to receive the application / javascript header when connecting scripts, but GitHub returns the text / plain header. Therefore, connecting scripts directly with GitHub is not recommended. Download the script to your host and use.
Source: https://habr.com/ru/post/144071/
All Articles