イベントキャプチャとバブリングの存在意義

Question

イベントが発生すると、ドキュメントルートから発生元までキャプチャが発生し、発生元に付いたらターーゲットフェーズとなり、バブリングで来た道を引き返すわけです。
この①キャプチャ → ②ターゲット → ③バブリングがなぜ、キャプチャをして、イベント発生元を補足？して、来た道を戻る、つまりバブリングするのかが分かりません。
何かしらの理由があってこの三つの動作が行われているわけですが、その理由は何なのでしょうか。

合っているか分かりませんが、唯一理解できているのは、キャプチャは、バブリング時に来た道を戻るための道を確保しているのだ、と書籍で拝見しました。

Answer 1

どうやら、ブラウザ戦争の時代に、NetScapeではイベントキャプチャだけがあって、IEにはイベントバブリングがあった、という時期があって、DOMを策定するにあたって、両者との互換性をはかるために両方とも実装した、ということのようです（Stackoverflow）。

キャプチャとバブリングのどちらを使うにしても、あるエレメントとその子孫に発生するイベントをまとめて拾えるので、うまく活用すれば便利です（実用上は、「子要素の側で処理を止められる」ということもあって、バブリングの利用が主流です）。

Answer 2

maisumakunさんの回答にあるブラウザ戦争の話、へぇ！と思いました

それはさておき、この方式はブラウザに限らずスタンドアロンアプリケーションでのGUI設計でも出てきます。例えばC#でのFormでもJavaFXでも同様の仕組みになっているので、おそらくイベントハンドリングを柔軟に行うための充分に一般性のある方式なのだと思います。

バブリングは普段よく使うように「より特定的なエレメントが興味のあるイベントのみハンドリングし」「上位で用意されているイベントハンドリングで済む場合は下位は単に実装を省略する」のに都合がよいと思います。

一方、キャプチャリングは、特定の上位エレメントの状態・モードに応じた「下位のエレメントのイベントの無効化・ルーティング・イベントの置き換え」に都合がよく、スタンドアロンアプリケーションの例だと、あるエレメントがdisabledな状態の場合、その配下のノードにイベント配送しないといった制御やフォーカスがあるエレメント以外にキーボードイベントを配送しないといった制御に向いていると思います。

これらはどちらか一方ではなく両方備わっている方がより柔軟な制御が可能となると思いますが、フォーカスにせよdisabledのようなものにせよ、あらかじめ用意されているエレメントの実装で充分なことが多いため、大抵の場合バブリングフェーズのみ意識していれば事足りるということなのだと思います。