web-dev-qa-db-ja.com

document.addEventListener（ "deviceready"、OnDeviceReady、false）;で3番目のパラメーター（false）が示すこと

3番目のパラメーター（false）は何を示しますか

document.addEventListener("deviceready",OnDeviceReady,false);

誰でも違いを示すためのスクリプト例を示すことができますか

javascripteventsjavascript-events
78
iJade

seCapture ：

trueの場合、useCaptureは、ユーザーがキャプチャを開始したいことを示します。キャプチャの開始後、指定されたタイプのすべてのイベントは、DOMツリーでその下のlistenersにディスパッチされる前に、登録されたEventTargetにディスパッチされます。ツリーを上方向にバブリングしているイベントは、キャプチャを使用するように指定されたリスナーをトリガーしません。詳細な説明については、 DOMレベル3イベント を参照してください。

10
lifus

これは歴史的な理由によるものです。ブラウザイベントシステムが最初に設計されたとき、それがどのように機能するかをモデル化する2つの矛盾する方法がありました。それらはイベントキャプチャおよびイベントバブリングと呼ばれていました。

たとえば、次のHTMLをご覧ください。

<html>
    <body>
        <a href="#">Content</a>
    </body>
</html>

a要素でイベント（クリックなど）が発生した場合、祖先要素は知っている必要がありますか？彼らがすべきであることが広く受け入れられました。しかし、質問はどの順序で通知されるべきかでした。 MicrosoftとNetscapeの開発者（これは、私たちが話している歴史的なhowのアイデアをあなたに与えるはずです！）意見が異なりました。

1つのモデルはイベントキャプチャでした（Netscape開発者が提唱）。これは、最初にhtml要素に通知し、ツリーを下って行きました：

  • html
  • body
  • a

もう1つのモデルは、イベントバブリング（Microsoft開発者が提唱）です。これは最初にターゲット要素に通知し、ツリーを上って行きました：

  • a
  • body
  • html

最終的な妥協案は、bothを実行することでした。

  • html（キャプチャ段階）
  • body（キャプチャ段階）
  • a（キャプチャ段階）
  • a（バブリングフェーズ）
  • body（バブリングフェーズ）
  • html（バブリングフェーズ）

そのため、イベントはツリーを下って行き、再びバックアップします。

これは、addEventListenerに到達するまでの長い方法です。 addEventListenerは、キャプチャ段階とバブリング段階の両方のイベントをリッスンします。 3番目のパラメーター（仕様では useCapture と呼ばれます）を使用すると、プログラマーは使用するフェーズを指定できます。

最新のブラウザでは、これはfalseにデフォルト設定されます。特にInternet Explorerはまだサポートしていないため、キャプチャフェーズを使用したい状況に出くわすことはおそらくないでしょう。ただし、古いブラウザではfalseを明示的に指定する必要があるため、一般的に下位互換性のために提供されています。

301
lonesomeday