Allow XPaths, RegExps and CSS selectors as fragment identifiers in URLs




6 years ago
5 years ago


(Reporter: navid.zamani, Unassigned)


(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)




6 years ago
[If this is the wrong component, please excuse me. The list is a bit confusing. :]

THE PURPOSE of this enhancement is, to enable linking to arbitrary document fragments, including for the purpose of embedding or highlighting parts of a document.
From ad blockers, to search engines, to content syndication to just making bookmarks and links more useful, even bordering on the original ideas of project XANADU, this has endless use cases for putting the user back in control of the web.

THE IDEA is, that instead of just being able to navigate to document anchors, by specifying


, one could also say any of


, making the following valid URLs:|domain/ig[2]/a>body>div>p>a

Note that the XPath and RegExp is the only potentially overlapping syntax here. Which is easil solved my disallowing “m/” in XPaths. (Unless I’m mistaken, that already is the case, except if somebody would declare a custom XML document type with “m” as the top-level tag. Which is extremely unlikely.)

An alternative syntax would be, to prefix the fragment indentifiers with another “protocol” if required, like so:|domain/ig[2]/a>body>div>p>a

THE IMPLEMENTATION is very likely extremely easy, since all the required components are already available and in a very robust state:
• URL fragment selector handler which can scroll to the selected element.
• RegExp engine (in JavaScript)
• XPath engine
• CSS selector engine (in the layout engine)
For the case where multiple fragments would be selected, they can be highlighted, scrolling to the first occurrence, just like with the text search.

I really hope this can be implemented, but this bug only serves as a “This is a thing that we could do, if somebody’s interested and has the time.” reminder. A roadmap wishlist kinda thing.
We support xpath in anchors already... in an XML document.  No one ever uses it.  We've been considering removing the implementation, since it just adds code and attack surface and is totally unused.

Comment 2

6 years ago
(In reply to comment #1)
Have you also told anyone about it? ;)
I’m a professional web developer, am very enthusiastic about these things, and never heard of it.

If it never gets used, yes, you are right, it would be an unnecessary complexity. But that’s just sad. :/

How about posting it on the major news aggregation sites (like Reddit, Slashdot, etc), and if that doesn’t change things, leave it as a compile option or add-on, so it’s possible to re-launch it, when the world is ready…
> Have you also told anyone about it? ;)

We have, over the 10+ years we've supported it....

Comment 4

6 years ago
(In reply to Vacation until Aug 19.  Do not ask for review. from comment #3)
> We have, over the 10+ years we've supported it....

Oh… wow… OK… I’ve nothing left to say… do what you want with this bug…

Thanks… I guess…

I’ll just go, and be sad now…

Comment 5

5 years ago
See the following add-ons. I've tested Hyper-Anchor and verified that it works in Firefox 32.0a1 (2014-06-01).

If you're building a website yourself, there's no reason why you can't add id attributes to elements.

When providing support, I sometimes come across very lengthy pages that have no id attributes. So something like this would be helpful and preferable to telling people "Read section X on the following page". But I can't say I encouter this frequently enough to make this a must-have feature.
• Bug 1019176.
• Bug 1019174.


5 years ago
Depends on: 978431

Comment 6

5 years ago
Sadly, this incredibly handy feature (xpath fragment identifiers) on sites that are bad at linking (like was removed from Firefox recently.
Stuff like  no longer functions.
You need to log in before you can comment on or make changes to this bug.