StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>First of all, thanks to you guys who answered! =)</p> <p>I've now done a lot more research and I believe I'm satisfied with my implementation. Here are the results of my research.</p> <p>First of all, <a href="http://github.com/blixt/js-hash" rel="noreferrer">my finished <code>Hash</code> library</a>. It's a stand-alone library with no dependencies. It has two functions: <code>Hash.init(callback, iframe)</code> and <code>Hash.go(newHash)</code>. The callback function is called whenever the hash changes with the new hash as its first argument, and as its second argument a flag indicating whether the callback is called due to initial state (<code>true</code>) or an actual change to the hash (<code>false</code>).</p> <blockquote> <p><a href="http://github.com/blixt/js-hash/raw/master/Hash.js" rel="noreferrer">Hash.js</a> (MIT license)</p> </blockquote> <p>I also made a jQuery plugin for making it easier to use. Adds a global <code>hashchange</code> event as well. See example in source code for how to use it.</p> <blockquote> <p><a href="http://github.com/blixt/js-hash/raw/master/jquery/jquery.hash.js" rel="noreferrer">jquery.hash.js</a> (MIT license)</p> </blockquote> <p>To see them in use, go to my JavaScript "realm" page:</p> <blockquote> <p><a href="http://blixt.org/js" rel="noreferrer">Blixt's JavaScript realm</a></p> </blockquote> <h3>Internet Explorer 8</h3> <p>Smooooth cruisin'! Just smack on one o' them <code>onhashchange</code> events to the <code>window</code> object (using <code>attachEvent</code>) and get the <code>location.hash</code> value in the event handler.</p> <p>It doesn't matter if the user clicks a link with a hash, or if you set the hash programmatically; history is kept perfectly.</p> <h3>Chrome, Firefox, Safari 3+, Opera 8+</h3> <p>Smooth cruisin'! Just poll for changes to the <code>location.hash</code> property using <code>setInterval</code> and a function.</p> <p>History works perfectly. For Opera, I set <code>history.navigationMode</code> to <code>'compatible'</code>. To be honest, I'm not sure what it does, I did it on recommendation from a comment in the YUI code.</p> <p><strong><em>Note</strong>: Opera needs some additional testing, but it has worked fine for me so far.</em></p> <p><strong><em>Surprise quirk bonus! (Can it be?!)</strong> It turns out that Firefox (only confirmed in 3.5+) decodes the <code>location.hash</code> property, so this can trigger a <code>hashchange</code> event twice (first for the encoded version then for the unencoded version.) There is a new version of my Hash.js library that takes this into account by using the <code>location.href</code> property instead (changes provided by Aaron Ogle.)</em></p> <h3>Internet Explorer 6, 7</h3> <p>Now it gets nastier. The navigation history in older Internet Explorer versions ignore hash changes. To work around this, the commonly accepted solution is to create an <code>iframe</code> and set its content to the new hash. This creates a new entry in the navigation history. When the user goes back, this changes the content of the <code>iframe</code> to its previous content. By detecting the change of content, you can get it and set it as the active hash.</p> <p>Checking for changes to the <code>location.hash</code> property is still needed to manual changes to the current address. Beware of the quirks I've mentioned below, though.</p> <p>While this solution seems to be the best one out there, it's still not perfect in Internet Explorer 6, which is a bit quirky about the back/forward buttons. Internet Explorer 7 works fine, though.</p> <p><strong><em>Surprise quirk bonus #1!</strong> In Internet Explorer 6, whenever there's a question mark in the hash, this gets extracted and put in the</em> <code>location.search</code> <em>property! It is removed from the</em> <code>location.hash</code> <em>property. If there is a real query string, however,</em> <code>location.search</code> <em>will contain that one instead, and you'll only be able to get the whole true hash by parsing the</em> <code>location.href</code> <em>property.</em></p> <p><strong><em>Surprise quirk bonus #2!</strong> If the</em> <code>location.search</code> <em>property is set, any subsequent</em> <code>#</code> <em>characters will be removed from the</em> <code>location.href</code> <em>(and</em> <code>location.hash</code><em>) property. In Internet Explorer 6 this means that whenever there's a question mark in the path or the hash, you'll experience this quirk. In Internet Explorer 7, this quirk only occurs when there's a question mark in the path. Don't you just love the consistency in Internet Explorer?</em></p> <p><strong><em>Surprise quirk bonus #3!</strong> If another element on the page has the same id as the value of a hash, that hash will totally mess up the history. So rule of thumb is to avoid hashes with the same id as any elements on the page. If the hashes are generated dynamically and may collide with ids, consider using a prefix/suffix.</em></p> <h3>Other browsers</h3> <p>Unless you've got an out-of-the-ordinary user base, you won't need to support more browsers. The browsers not listed above are in the <1% usage category.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload