XPath или querySelector?

Question

XPath может делать все, что может делать querySelector, и даже больше, так когда же вы выберете последнее? Я не видел никаких тестов скорости, сравнивающих эти два, поэтому сейчас я выбираю, основываясь на краткости синтаксиса, которая кажется произвольной.

Редактировать: Я, вероятно, должен был заявить, что я пишу сценарии Greasemonkey для Firefox, поэтому я не беспокоюсь о совместимости между браузерами и предпочел бы не включать какие-либо библиотеки.

Answer 1

Какой браузер вы используете? В Safari (или iPhone) querySelector и querySelectorAll намного быстрее, чем XPath. IE вообще не поддерживает XPath, а IE6 и IE7 не поддерживают querySelector. Самым быстрым кроссбраузерным механизмом выбора является Sizzle , созданный Джоном Резигом. Sizzle также является основным механизмом выбора, используемым в jQuery. Он использует querySelector, где это уместно, и обычные методы DOM, где querySelector недоступен.

Answer 2

С точки зрения функциональности вам лучше всего использовать библиотеку, которая включает механизм выбора, и многие из них (например, MooTools, Dojo, Prototype) уже используют XPath для выполнения некоторых классов запросов. Вы должны быть в состоянии рассчитывать на хорошую библиотеку, выбирающую для вас быстрый метод.

XPath может делать все, что может делать querySelector (я думаю, что это утверждение немного подозрительно, но это не так), но querySelector и querySelectorAll поддерживаются не всеми браузерами, поэтому на самом деле мы должны сравнивать XPath с собственные методы запросов DOM (т. е. getElementsByTagName, getElementById, querySelector, стандартные методы обхода и фильтрации и т. д.)

Использование собственных методов фильтрации DOM требует знания особенностей и ограничений браузера и быстро становится непрактичным для сложных запросов, если вы не используете библиотеку (например, jQuery или MooTools) для устранения несоответствий. Причина, по которой нативные методы DOM (будь то через прокси, такие как jQuery или пользовательские реализации) часто выбираются вместо XPath, заключается в том, что они предлагают гораздо большую гибкость, чем XPath. Например, если вы хотите отфильтровать проверенные входные данные, «скрытые» элементы или отключенные входные данные XPath не подходят, но jQuery предоставляет вам псевдоклассы: checked,: hidden и: disabled.

Answer 3

Синтаксис CSS великолепен по двум причинам:

• Это на порядок быстрее и требует меньше ресурсов, чем более сложный 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 вручную с помощью кода (который становится ужасно быстрым).

Лично (и я один из сопровождающих Greasemonkey), я использую очень крошечную библиотеку on.js для всех моих потребностей по нарезке узлов - что дает мне комбинацию обоих XPath (когда я это нужно) и CSS (который я обычно использую почти все время) - в основном потому, что он позволяет мне отделить весь код, связанный с копанием частей страницы, которые мне нужно переварить, в заголовок скрипта, чтобы мой код получал обслуживал все, что ему нужно, и может быть связано с тем, чтобы на самом деле делать веселые или замечательные вещи для веб-страниц.

Веб-браузеры очень сильно оптимизированы для очень быстрого запуска javascript, и я бы порекомендовал использовать то, что делает вас наиболее эффективным и счастливым как разработчик, по сравнению с тем, что заставляет браузер выполнять наименьшее количество кода. В частности, одно из побочных преимуществ on.js заключается в том, что он автоматически помогает сценариям вообще не запускаться вообще, на страницах, где узлы, о которых вы думали, что были рядом, оказываются не вместо того, чтобы уничтожать страницу.

Answer 4

Вы бы использовали querySelector, только если вы еще не изучили XPath, но знаете только о селекторах CSS.Помимо этого, синтаксис XPath может быть более сложным даже для простых запросов.Поэтому, если вам не нужна мощность, обеспечиваемая XPath, вместо этого может быть проще использовать CSS-селекторы.

Вы должны знать о двух вещах:

• id селекторы don 't работать с querySelector, когда используется на чистом XML (или, по крайней мере, ненадежно)
• querySelector работает только с селекторами, которые в настоящее время поддерживает браузер, поэтому, если он не поддерживает некоторые селекторы CSS3, вы не можете использоватьте.