Skip to content

WIP: Refs #178 - Proposal: hide-xpath-query

Andrea Giammarchi requested to merge agiammarchi/adblockpluscore:xpath into next

Background

We have discussed the possibility to have XPath as extra powerful way to retrieve DOM nodes to, eventually, hide.

This MR is an attempt to provide such functionality via a snippet, so that we can start experimenting with this practice.

Pros

The hide-xpath-query '//complex[@xpath="selector"]' provides the following features that are missing from regular CSS selectors:

  • the ability to match and get .../parent::*[@class=..] or .../ancestor::div[not(@attr)]
  • the ability to address the content of an element while checking
  • the ability to combine via and and or, plus parenthesis, various conditions to match

This snippet is also registering these XPath queries through MutationObserver so that with pages that have infinite content, the elementHide will keep working on the fly.

Cons

When I've proposed this approach I was aware that browsers reliability might vary, but I didn't know the following points:

  • all browsers seem to support up to XPath 1.0, but no more than that
  • because of the previous point, it's basically impossible to compose, in a reasonable way, nodes content to search with

The major missing thing is indeed the string-join(descendant-or-self//text(), ''), so that nodes with a composed content as in <p><b>Hello</b> World</p> cannot be easily addressed searching, as example, the string Hello World.

This might make this snippet not as useful/powerful as I've initially thought, but at least now we have some little know-how, and research, behind current XPath features, and status, across browsers.

Edited by Hubert Figuière

Merge request reports