私は現在、アドレスバーのハッシュ部分への変更の履歴を追跡するJavaScriptライブラリを実装しています。ハッシュ部分に状態を保持してから、戻るボタンを使用して前の状態に戻ることができるという考え方です。
最近のほとんどのブラウザーでは、これは自動でありlocation.hash、変更についてプロパティをポーリングするだけで済みます（IE8では、それを行う必要はありませんonhashchange。イベントに関数をアタッチするだけです）。
私が疑問に思っているのは、履歴を追跡するためにどのような異なる方法がありますか？Internet Explorer 6/7/8、Firefox、Chromeで動作することがテストされている機能を実装しましたが、他のブラウザーはどうですか？これが私が現在履歴を保持する方法です：
編集：さまざまなブラウザのウォークスルーについては、代わりに以下の私の答えを参照してください。
まず、回答してくださった方々、ありがとうございます！=)
私は今、さらに多くの調査を行っており、実装に満足していると思います。これが私の研究の結果です。
まずは、私の完成したHashライブラリ。依存関係のないスタンドアロンのライブラリです。と の 2 つの機能がHash.init(callback, iframe)ありHash.go(newHash)ます。コールバック関数は、最初の引数として新しいハッシュを使用してハッシュが変更されるたびに呼び出され、2 番目の引数として、コールバックが初期状態 ( true) またはハッシュへの実際の変更( ) によって呼び出されるかどうかを示すフラグfalseです。
Hash.js (MIT ライセンス)
また、使いやすくするために jQuery プラグインも作成しました。hashchangeグローバルイベントも追加します。使用方法については、ソース コードの例を参照してください。
jquery.hash.js (MIT ライセンス)
それらが使用されていることを確認するには、私の JavaScript の「レルム」ページにアクセスしてください。
スムーズなクルージング！onhashchangeそれらのイベントの 1 つwindowを ( を使用して) オブジェクトに叩きつけ、イベント ハンドラーで値attachEventを取得します。location.hash
ユーザーがハッシュ付きのリンクをクリックするか、プログラムでハッシュを設定するかは問題ではありません。履歴は完全に保持されます。
スムーズクルージング！location.hash関数を使用してプロパティへの変更をポーリングするだけsetIntervalです。
歴史は完全に機能します。Opera の場合、 に設定history.navigationModeし'compatible'ます。正直なところ、私はそれが何をするのかよくわかりません.YUIコードのコメントからの推薦でそれをやった.
注: Opera には追加のテストが必要ですが、これまでのところ問題なく動作しています。
驚きの癖ボーナス！(そうでしょうか?!) Firefox (3.5+ でのみ確認済み) はlocation.hashプロパティをデコードするため、これによりhashchangeイベントが 2 回トリガーされることが判明しました (最初はエンコードされたバージョンで、次にエンコードされていないバージョンで発生します)。代わりにプロパティを使用してこれを考慮した Hash.js ライブラリlocation.href(Aaron Ogle による変更)。
今ではもっと厄介になります。Internet Explorer の古いバージョンのナビゲーション履歴は、ハッシュの変更を無視します。これを回避するために、一般的に受け入れられている解決策は、 を作成し、iframeそのコンテンツを新しいハッシュに設定することです。これにより、ナビゲーション履歴に新しいエントリが作成されます。ユーザーが戻ると、これにより のコンテンツがiframe以前のコンテンツに変更されます。コンテンツの変更を検出することで、それを取得してアクティブなハッシュとして設定できます。
location.hash現在のアドレスを手動で変更するには、プロパティへの変更を確認する必要があります。ただし、以下で説明する癖に注意してください。
このソリューションは最善の方法のように見えますが、Internet Explorer 6 ではまだ完全ではありません。Internet Explorer 6 では、戻る/進むボタンが少し変わっています。ただし、Internet Explorer 7 は正常に動作します。
驚きの癖ボーナス #1! Internet Explorer 6 では、ハッシュに疑問符がある場合は常に、これが抽出されて location.search プロパティに入れられます! プロパティから削除され location.hash ます。ただし、実際のクエリ文字列がある場合は、 location.search 代わりにそれが含まれ、プロパティを解析することによってのみ真のハッシュ全体を取得でき location.href ます。
驚きの癖ボーナス #2! プロパティが設定されている場合、 location.search 後続の # 文字は location.href (and location.hash) プロパティから削除されます。Internet Explorer 6 では、これは、パスまたはハッシュに疑問符がある場合は常に、この癖が発生することを意味します。Internet Explorer 7 では、パスに疑問符がある場合にのみ、この癖が発生します。Internet Explorer の一貫性が気に入っていませんか?
驚きの癖ボーナス #3! ページ上の別の要素がハッシュの値と同じ id を持つ場合、そのハッシュは履歴を完全に台無しにします。したがって、経験則として、ページ上の要素と同じ ID を持つハッシュを避けることです。ハッシュが動的に生成され、ID と衝突する可能性がある場合は、プレフィックス/サフィックスの使用を検討してください。
通常とは異なるユーザー ベースを持っていない限り、これ以上多くのブラウザーをサポートする必要はありません。上記以外のブラウザーは、使用率が 1% 未満のカテゴリに属します。
これまでの努力に基づいて、 YUI Browser History Managerを見たことがあると思いますが、念のため...
彼らは実装について素晴らしい記事を書いており、ソースコードは非常に読みやすいと思います。
Opera についての説明は次のとおりです。
* location.hash is a bit buggy on Opera. I have seen instances where
* navigating the history using the back/forward buttons, and hence
* changing the URL, would not change location.hash. That's ok, the
* implementation of an equivalent is trivial ... more below
ソースを検索すると、Safari 1.x および 2.0 の対応もいくつか見つかりました。興味を持っていただけそうです。
それが役立つことを願っています。
私はあなたのニーズを完全に理解しているかどうかはわかりませんが、同様のことを実装するためにReally Simple Historyライブラリ（ http://code.google.com/p/reallysimplehistory/ ）を使用しました。あなたはここでそれを見ることができます：http ：//whiteoak.sourceforge.net/
GWT は履歴管理を提供します。また、MVP フレームワークの不可欠な部分でもあります。また、場所とアクティビティを使用して履歴 API を強化しました。