12

XPath は、querySelector が実行できるすべてのこと、およびそれ以上のことを実行できます。この 2 つを比較する速度のベンチマークは見たことがありません。そのため、現時点では構文の簡潔さに基づいて選択していますが、これは恣意的なものに思えます。

編集: おそらく、私は Firefox 用の Greasemonkey スクリプトを作成していると述べるべきだったので、ブラウザー間の互換性について心配しておらず、ライブラリを含めたくありません。

4

4 に答える 4

7

どのブラウザを使用していますか？Safari（またはiPhone）では、querySelectorとquerySelectorAllはXPathよりもはるかに高速です。IEはXPathをまったくサポートしておらず、IE6とIE7はquerySelectorをサポートしていません。最速のクロスブラウザセレクタエンジンは、JohnResigによって作成されたSizzleです。Sizzleは、jQueryで使用されるメインのセレクターエンジンでもあります。適切な場合はquerySelectorを使用し、querySelectorが使用できない場合は通常のDOMメソッドを使用します。

于 2009-06-30T17:51:26.713 に答える
4

機能に関しては、セレクター エンジンを含むライブラリを使用するのが最善の策であり、それらの多く (MooTools、Dojo、Prototype など) は、いくつかのクラスのクエリを実行するために既に内部で XPath を使用しています。断食法を選択してくれる優れたライブラリを当てにできるはずです。

XPath は、querySelector が実行できるすべてのことを実行できる可能性があります (このステートメントは少し疑わしいと思いますが、それは的外れです) が、querySelector と querySelectorAll はすべてのブラウザーでサポートされているわけではないため、XPath をネイティブ DOM クエリと比較する必要があります。メソッド (つまり、getElementsByTagName、getElementById、querySelector、標準のトラバーサルおよびフィルタリング メソッドなど)

ネイティブ DOM フィルタリング メソッドを使用するには、ブラウザーの癖と制限に関する知識が必要であり、ライブラリ (jQuery や MooTools など) を使用して矛盾を解決しない限り、複雑なクエリはすぐに非現実的になります。XPath よりもネイティブ DOM 手法 (jQuery などのプロキシを使用する場合でも、カスタム実装を使用する場合でも) が選択されることが多いのは、XPath よりもはるかに柔軟性が高いためです。たとえば、チェック済みの入力、「隠し」要素、または無効な入力をフィルター処理する場合、XPath は不足していますが、jQuery は :checked、:hidden、および :disabled 疑似クラスを提供します。

于 2009-06-30T20:35:12.913 に答える
2

XPath をまだ学んでおらず、CSS セレクターについてしか知らない場合にのみ、querySelector を使用します。それ以外では、XPath 構文は、単純なクエリであってもより複雑になる可能性があります。したがって、XPath によって提供される機能が必要ない場合は、代わりに CSS セレクターを使用する方が簡単かもしれません。

次の 2 つの点に注意してください。

  • id セレクターは、純粋な XML で使用する場合、querySelector では機能しません (または、少なくとも信頼性がありません)。
  • querySelector は、ブラウザーが現在サポートしているセレクターでのみ機能するため、一部の CSS3 セレクターがサポートされていない場合は、それらを使用できません。
于 2011-04-24T15:53:21.263 に答える
1

CSS 構文が優れている理由は 2 つあります。

  • これは、より複雑な XPath よりも桁違いに高速で、リソースの消費が少なくなります。
  • 探したいものが css セレクターで見つかる場合、同じことを行う対応する XPath クエリは、ほとんどの場合、はるかに長くなり、読みにくくなります。

適切なケース: 次の css セレクターを使用します。h1.header > a[rel~="author"]

機能的な XPathに相当する最短のものは次のようになります。//h1[contains(" "+normalize-space(@class)+" "," header ")]/a[contains(" "+normalize-space(@rel)+" "," author ")]

…これは、読み取りと書き込みの両方がはるかに困難です。

代わりにこの XPath を記述した場合://h1[@class="header"]/a[@rel="author"]

…次のようなマークアップを誤って見逃していたでしょう<h1 class="article header"><a rel="author external" href="/mike">...</a></h1>

ただし、本当にXPath が必要な場合は、コードを使用して手動で DOM を歩き回る必要がない限り (非常に高速になります)、XPath が唯一の選択肢となります。

個人的に (そして私は Greasemonkey のメンテナーの 1 人です)、on.jsノード スライスのすべてのニーズに非常に小さなライブラリを使用しています。ほとんどの場合) – 主に、消化する必要があるページの部分を掘り下げることを扱うすべてのコードをスクリプトヘッダーに分離できるため、コードが必要なものすべてを提供され、すべてについてのことができます。実際にウェブページに楽しいことや素晴らしいことをしている.

Web ブラウザーは、javascript を非常に高速に実行するために非常に最適化されています。私があなたであれば、ブラウザーが実行するコードの量が最も少ないものよりも、開発者として最も効率的で満足できるものを使用することをお勧めします。ただし、特にの副次的な利点の 1 つは、ページを破壊するのではなく、ノードが周囲にあると思っon.jsていたページで、スクリプトがまったく実行されないことが多いのに自動的に役立つことです。

于 2012-11-25T05:58:40.477 に答える