XPath发生了什么变化?

2020-10-30 20:55:12

在2007年革命性地释放了从来不存在的css选择器之后,该规范从v1.0升级到了当前推荐的v3.1,但是浏览器在v1.0…中停止了。我们要错过了!

这两个标准之间的根本区别在于,一个标准生来就是在所有“轴”上爬行和分析DOM树,而另一个工作是对DOM进行实况处理,而没有任何方法爬行它的内容。

仅此而已:XPath是一个搜索工具,而CSS是一个实时“绘图”工具,因此具有丰富的样式功能,但在DOM树分析方面很差。

这里有一个示例:即使css:有(...)。选择器是最新规范的一部分,到目前为止还没有浏览器实现它,而在XPath中是:

这只触及了XPath中可能实现的功能的皮毛,但是通过CSS是不可能实现的。

在本例中,我们找到一个与[方括号]内的任何表达式相匹配的元素,然后向上爬行DOM树以找到它的包装器,方法与element.est(';div.wire';)相同,除非使用XPath通过浏览器检查条件,不需要JS,不需要if(el.est(...))。验证:如果找到,则返回。

最上面是草莓,XPath也可以查询和返回文本节点,这是CSS根本不会关心/知道的!

首先,检查这个非常棒的CSS到XPath转换程序,阅读该转换程序提供的额外案例,并检查其源代码以查找更多额外的内容,例如图标(...)。要以不区分大小写的方式匹配任何内容,请打开DevTools并键入$x,以意识到提供了开箱即用的XPath实用程序。尝试$x(';//body';)读出结果,并尝试您能想到的任何类型的查询。

不幸的是,2007年,也就是XPath在大多数著名框架中作为超级CSS选择器出现的那一年,有人决定不再计划进一步更新XPath引擎,所以我们只能使用1.0版,至少在不同浏览器之间一致实现。

这里有一个跨浏览器和跨环境函数,它复制了DevTools$x(...)。帮助者带来:

//使用JSDOM Too函数的基本XPath帮助器X(path,root=document){const flag=XPathResult.ORDERED_NODE_SNAPSHOT_TYPE;const query=document(path,root,null,flag,null);const result=[];for(let i=0,{snapshotLength}=query;i<;snapshotLength;i++)result t.ush(query.snapshotItem(I));return result;}。

…。现在我们有了一种执行强大查询的方法,我们所缺少的就是使用正则表达式的能力,这是在2010年通过XPath2.0引入的,但是在任何浏览器…中都没有提供。是吗?

由于当前版本是3.1,我相信仍然有很多关于xpath的用例,但是当谈到Selenium测试时,看起来每个人都至少更新了v2.0…。但是,如果XPath被认为是爬虫程序的强大工具,那么浏览器为什么不能为JS提供一种释放XPath全部潜力的方法呢?

Xpath的最好之处在于,几乎不需要JS来一次执行大量操作,而不是查询一个目标,通过JS验证其周围条件,然后找到可能的父级,然后执行…。我们都知道这种舞蹈,它比任何XPath查询都枯燥、缓慢,而且更容易出错,就好像没有目标节点、没有目标节点、没有要检查/过滤的东西一样,引擎已经为我们做了这些,这就是黄金!

这就像Web平台的“我的圣诞愿望”:有一种非常强大的查询语言,它在浏览器中本地运行,可以帮助减少许多手写的JS操作来到达所需的节点,另外,有一种语言天生就能满足任何DOM树搜索需要,它可以定位各个方向的节点,将RegExp添加到等式中将使复杂的搜索成为“一行程序”,所以我希望浏览器供应商能尽快提供XPath的复兴,以适应现代复杂的SPA和PWAS世界。

感谢您考虑对平台进行这次改进,也感谢您阅读♥️