XPath发生了什么变化？

在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世界。

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

另外，我已经拿到了一份提案，希望供应商会感兴趣，并听取他们的意见