Open Bug 905766 Opened 11 years ago Updated 2 years ago

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

Categories

(Core :: DOM: Navigation, enhancement)

enhancement

Tracking

()

People

(Reporter: navid.zamani, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: parity-chrome)

[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

  protocol://server.tld/path#someAnchor

, one could also say any of

  protocol://server.tld/path#someRegex
  protocol://server.tld/path#someXPath
  protocol://server.tld/path#someCSSSelector

, making the following valid URLs:

  https://example.com/index.html#myAnchor
  https://example.com/index.html#m/example|domain/ig
  https://example.com/index.html#/html/body/div/p[2]/a
  https://example.com/index.html#html>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:

  https://example.com/index.html#myAnchor
  https://example.com/index.html#match=/example|domain/ig
  https://example.com/index.html#xpath=/html/body/div/p[2]/a
  https://example.com/index.html#select=html>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.
(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....
(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…
See the following add-ons. I've tested Hyper-Anchor and verified that it works in Firefox 32.0a1 (2014-06-01).
• https://addons.mozilla.org/firefox/addon/hyper-anchor/https://addons.mozilla.org/firefox/addon/advanced-bookmaks-add-on/

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.
Depends on: 978431
Sadly, this incredibly handy feature (xpath fragment identifiers) on sites that are bad at linking (like launchpad.net) was removed from Firefox recently.
Stuff like http://antimatter15.com/wp/2009/11/xpath-bookmark-bookmarklet/  no longer functions.

This is now available in Chrome. Spec is here : https://github.com/WICG/scroll-to-text-fragment/

I'd love to see this in Firefox as well !

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: parity-chrome

Arnaud, there are various issues with the "scroll to text fragment" proposal that make Mozilla hesitant to implement it, last I checked. See https://github.com/mozilla/standards-positions/issues/194 for the discussion.

And I should note that "scroll to text fragment" does NOT allow "XPaths, RegExps, and CSS selectors", nor does the fragmention proposal which aims to address the same use case. This issue as filed is almost certainly "wontfix".

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.