XPath 可以做所有 querySelector 可以做的事情,甚至更多,那么你什么时候会选择后者呢?我还没有看到任何比较两者的速度基准,所以现在我根据语法简洁性进行选择,这似乎有点武断。
编辑:我可能应该说我正在为 Firefox 编写 Greasemonkey 脚本,所以我不担心跨浏览器的兼容性,并且宁愿不包含任何库。
XPath 可以做所有 querySelector 可以做的事情,甚至更多,那么你什么时候会选择后者呢?我还没有看到任何比较两者的速度基准,所以现在我根据语法简洁性进行选择,这似乎有点武断。
编辑:我可能应该说我正在为 Firefox 编写 Greasemonkey 脚本,所以我不担心跨浏览器的兼容性,并且宁愿不包含任何库。
你使用的是什么浏览器?在 Safari(或 iPhone)中,querySelector 和 querySelectorAll 比 XPath 快得多。IE 根本不支持 XPath,IE6 和 IE7 也不支持 querySelector。最快的跨浏览器选择器引擎是Sizzle,由 John Resig 创建。Sizzle 也是 jQuery 中使用的主要选择器引擎。它在适当的地方使用 querySelector,在 querySelector 不可用的地方使用普通的 DOM 方法。
就功能而言,您最好的选择是使用包含选择器引擎的库,其中许多(例如 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 伪类。
如果您还没有学习过 XPath 但只知道 CSS 选择器,则只能使用 querySelector。除此之外,即使对于简单的查询,XPath 语法也可能更复杂。因此,如果您不需要 XPath 提供的功能,使用 CSS 选择器可能会更容易。
你应该注意两点:
CSS 语法很棒有两个原因:
举个例子:使用这个 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(我倾向于使用)的组合几乎所有时间)——主要是因为它让我可以将处理挖掘我需要消化的页面部分的所有代码分离到脚本标题中,这样我的代码就可以得到它需要的所有东西,并且可以全部用于实际上对网页做有趣或伟大的事情。
Web 浏览器为非常快速地运行 javascript 进行了非常多的优化,如果我是你,我会建议使用任何让你作为开发人员最高效和最快乐的东西,而不是让浏览器运行最少的代码的东西。但是,特别是它的一个附带好处on.js
是,它会自动帮助脚本通常根本不运行,在您认为节点所在的页面上,结果不是,而不是破坏页面。