XPath peut faire tout ce que QuerySelector peut faire, et plus encore, alors quand choisiriez-vous ce dernier? Je n'ai vu aucun point de repère de vitesse comparant les deux, alors maintenant, je choisis maintenant sur la base de la concision de la syntaxe, qui semble un peu arbitraire.
Edit: J'aurais probablement dû dire que j'écris des scripts de Greasemonkey pour Firefox, donc je ne suis donc pas inquiet pour la compatibilité entre navigateur et préféreriez ne pas inclure de bibliothèques.
4 Réponses :
Quel navigateur utilisez-vous? Dans Safari (ou iPhone), QuerySelector et QuerySelectorallall sont beaucoup plus rapides que XPath. Ie ne prend pas en charge XPath et IE6 et IE7 ne prend pas en charge QuerySelector. Le moteur de sélection de navigateur croisé le plus rapide est Sizzle , créé par John Resig. Sizzle est également le moteur de sélecteur principal utilisé dans JQuery. Il utilise QuerySelector, dans le cas des méthodes appropriées et normales de DOM où QuerySelector n'est pas disponible.
XPath est beaucoup plus rapide que QuerySelectorally dans le chrome 35.0.1916.153 m, Opera 24.0.1555.0 (à la fois avec un moteur de clignotement), mais QuerySelectorallall est beaucoup plus rapide que XPath dans Firefox 30.0 lors de l'exécution de ce test: jsperf.com/xpath-vs-queryselectorall . Donc, cela dépend vraiment du navigateur utilisé - ce qui pourrait être un point de vue pertinent lorsque par exemple. Développer une extension de navigateur sans utiliser de bibliothèques externes ... mais uniquement si ces millisecondes vraiment comportent, ce qui, je pense, est un cas relativement rare.
En termes de fonctionnalité, votre meilleur pari sera d'utiliser une bibliothèque comprenant un moteur de sélecteur, et beaucoup d'entre eux (par exemple, MotoTools, Dojo, prototype) utilisent déjà XPath en interne pour exécuter des classes de requêtes. Vous devriez être capable de compter sur une bonne bibliothèque en choisissant la méthode à jeun.
XPath pourrait être capable de faire tout ce que QuerySelector peut faire (je pense que cette affirmation est un peu suspect, mais c'est à côté du point), mais QuerySelector et QuerySelectorallall ne sont pas pris en charge par tous les navigateurs, nous devrions donc vraiment comparer XPath à méthodes de requête DOM autochtones (c.-à-d. GetelementsByTagname, GetElementByID, QuerySelector, Traversal Standard et Méthodes de filtrage, etc.)
Utilisation de méthodes de filtrage Dom natif nécessite une connaissance des bizarreries et des limitations et devient rapidement une interrogation complexe à moins que vous n'utilisiez une bibliothèque (par exemple, jQuery ou motoools) pour repasser les incohérences. La raison pour laquelle les techniques de DOM autochtones (par le biais d'une proxy comme jQuery, ou implémentations personnalisées) sont souvent choisies sur XPath, c'est qu'ils offrent une plus grande flexibilité que XPath. Par exemple, si vous souhaitez filtrer pour des entrées vérifiées, des éléments "masqués" ou des entrées désactivées XPath apparaît courte mais JQuery vous donne: vérifié,: Caché et: pseudo-classes handicapés.
Vous n'utiliseriez que QuerySelector si vous n'avez pas encore appris XPath mais que vous connaissez uniquement les sélecteurs CSS. Autre que cela, la syntaxe XPath peut être plus complexe, même pour des requêtes simples. Donc, si vous n'avez pas besoin de la puissance fournie par XPath, il peut être plus facile d'utiliser des sélecteurs CSS à la place.
Vous devez être au courant de deux choses:
Syntaxe CSS est génial pour deux raisons:
cas in Point: Prenez ce sélecteur CSS: Son plus court XPath fonctionnel équivalent serait ... qui est à la fois beaucoup plus difficile à lire et à écrire.
Si vous avez écrit ce XPath à la place: ... vous auriez incorrectement le balisage manqué comme Lorsque vous êtes vraiment besoin xpath, cependant, c'est la seule option, à moins que vous ne vouliez me promener manuellement avec le code (qui devient hideux rapide).
Personnellement (et je suis l'un des mainteneurs de Greasemonkey), j'utilise le très minuscule Les navigateurs Web sont très optimisés pour exécuter JavaScript vraiment rapidement, et si j'étais vous, je vous recommanderais d'utiliser tout ce qui vous rend le plus efficace et heureux en tant que développeur, sur ce qui rend le navigateur exécuter le moins de code. L'un des avantages latéraux de H1.Header> A [rel. = "Auteur"]
// h1 [contient ("+ normalisation-espace (@class) +" "," en-tête ")] / a [contient ( "" + Normaliser-Space (@Rel) + "", "Auteur")]
// h1 [@ class = "en-tête"] / a [@ rel = "auteur"]
... < / code>
on.js bibliothèque pour tous mes nœuds Thicing Besoins - ce qui me donne une combinaison de XPath (pour quand j'en ai besoin de cela), et que CSS (que j'ai tendance à utiliser presque tout le temps) - principalement parce qu'il laisse Moi séparez tout le code qui traite de creuser des parties d'une page que je dois digérer, dans l'en-tête de script afin que mon code soit servi tous les produits dont il a besoin, et peut être tout au sujet de la réception des pages Web.
on.js en particulier est qu'il aide automatiquement les scripts souvent ne pas être exécutés du tout, sur les pages où les nœuds que vous pensaient étaient autour , éteignez pas pour être, au lieu de détruire la page.
Ne sont-ils pas deux choses totalement différentes? Je pensais que QuerySelector était pour CSS Selectors et XPath est destiné aux nœuds / attributs XML.
Les sélecteurs CSS et XPath fonctionnent sur le DOM et, comme des documents XML et HTML sont définis en termes de modèle d'objet de document, vous pouvez utiliser ces jours-ci à la fois sur, grâce à
QuerySelector * etetDocument.valuez . Dans le monde en arrière, c'est-à-dire (même compter IE10), le soutien de XPath natif n'est toujours pas là pour les documents HTML, cependant.