Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: A more capable URL #fragment #3509

Closed
nuragic opened this issue Feb 26, 2018 · 13 comments
Closed

Proposal: A more capable URL #fragment #3509

nuragic opened this issue Feb 26, 2018 · 13 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@nuragic
Copy link

nuragic commented Feb 26, 2018

Hi,

First of all, thanks for being open to admitting proposal from everyone! This is my first submission, I hope to not waste anyone time, apologize in advance if that will be the case. I’ll try to summarize as much as possible what are the use cases I found and why I think it'd be great to have this feature.

When we share a page, we often want to point to a specific part of that page, and that’s currently possible by using #anchors.

E.g. https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element

That’s a great feature, and indeed it works on the above page cause there’re hundreds of IDs taking care of pointing to the right section of the page.

However, we can also find millions of blog posts, articles, etc. without IDs in their markup, with the result of not being able to share those pages plus pointing to a specific section of that page at the same time.

Suppose that I want to share the post below, specifically the section titled 12. Recruiters:

E.g. https://techbeacon.com/14-things-developers-love-hate

It’d be indeed possible using Data URIs: if I control the markup I could create an anchor element that runs this script when opened:

var w = window.open('https://techbeacon.com/14-things-developers-love-hate');
w.onload = function() {
  w.scrollTo(0, (w.document.querySelectorAll('h2')[12]).offsetTop);
}

But with the current state of the art it's impossible (AFAIK) to share a "regular" URL that, when opened, will make the browser scroll down directly to a specific element. I just mean putting an URL string in the address bar or sharing via any social network and making the above example work.

I believe that I’m not the first one asking something like this, but I couldn’t find any similar proposals.

I did found some people proposal about XPath in the URL but I’m thinking about something simpler and of course it’d only affect the semantic of the #fragment part... Like enabling in some way to use the Selectors API in the fragment.

E.g. https://techbeacon.com/14-things-developers-love-hate#$('h2')[12]

Do you think that something like this would be possible?

Thanks!

@Jamesernator
Copy link

Obviously with the selectors form only developers are likely to be able to construct those urls so what's the point if an arbitrary user can't create these urls in say the right-click context menu?

A similar alternative that could be used by essentially any user is some form of Link to this part of the page which constructs a selector-ish thing to find that specific part of the content (maybe longest unique text fragment e.g. to link to my comment you could have: https://github.com/whatwg/html/issues/3509#textFind=Obviously+with+the+selectors). Or perhaps a direct selector like html>body>...>p:nth-child(11)`

But I'm still wary of the fact that whether it composes a selector automatically or looks at a text prefix or basically anything like there's a significant chance compared to the ID mechanism that the link no longer works. For example what if someone else creates a comment with the same prefix, how would a browser generate a sufficiently specific selector that isn't likely to change at a moment's notice?

If you want users to be able to jump to arbitrary locations on your site you can always auto-generate IDs for your elements, but for creating these links automatically from an arbitrary site sounds is likely to be a difficult problem.

@js-choi
Copy link

js-choi commented Mar 1, 2018

The W3C Web Annotation Working Group finished some standards that, among other things, attempt to codify generic selectors for documents. It has some buy in from ebook/article publishers; it’s being used for annotations targeting specific selections by the Web Publishing Group, which is the successor to the people who governed ePub. Might be worth a look for you.

As for elaborating URL fragment selectors, The WHATWG has pretty strict criteria for adding any new proposals to HTML itself. Take a look at WHATWG Working Mode. It suggests that new proposals are incubated separately from the HTML Standard. Many such new proposals are incubating in the WICG, which encourages proposals and feedback from web developers in general. You might have more luck posting this in WICG and soliciting support from the community and from browser vendors there.

@nuragic
Copy link
Author

nuragic commented Mar 2, 2018

Thanks so much for your feedback! 🙌

@Jamesernator

Great points. The Link to this part of the page you suggested in the context menu (or similar option) would be basically what would enable every user to generate this type of links with a "fragment selector". Regarding matching by the element's content, e.g. Obviously with the selectors form… I thought about it at first but I believe that it would be even more problematic; besides, as the current #anchors basically match elements with IDs (or name), this addition would be more inline with the actual behavior which also targets elements (but with more selectors).

For the example you provided (linking to your comment in this thread) I'd say that the generated selector to be put in the fragment would be more like:

https://github.com/whatwg/html/issues/3509#$('td.comment-body')[1].

creating these links automatically from an arbitrary site sounds is likely to be a difficult problem.

Yeah, not so easy as it sounds... But at the end of the day, the DOM is a well known data structure 🌲 😄. Generating the simplest selector for any given target would be a good exercise to apply some good algorithm. I'd like to make a PoC for this, I was thinking about creating a Chrome/FF extension to illustrate this feature.

how would a browser generate a sufficiently specific selector that isn't likely to change at a moment's notice?

This proposal would have exactly the same gotchas as the current behavior, right? I mean, people could publish/share e.g. http://www.example.com#section-id, then remove/change the section id in the markup and the anchor will be "broken"... The same would happen in this case.

@js-choi

Wow, the Annotation Data Model spec you mentioned seems exactly what I'm looking for! 😮 However, having looked at the examples table, I'm able to understand everything but the HTML example: it says namedSection 😕 💭 ... what that means? Wondering what would be the resulting URL for the examples provided above.

And finally thanks for suggesting to post this in the WICG, will do so.

@js-choi
Copy link

js-choi commented Mar 2, 2018

@nuragic: You’re probably referring to the namedSection example in the second table at https://www.w3.org/TR/annotation-model/#fragment-selector. That’s just an example of an already-valid URL-fragment selector #namedSection that targets an HTML DOM node with id=namedSection. The Web Annotation standards’ Selectors are just JSON data structures, of which only one type uses existing standards for URL fragments. Others use CSS selectors, XPath, text quotes, text positions, SVG shapes, and so on. There is no current buy-in major browser vendor yet that I know of, but there is buy-in from the Web Publishing Working Group, which includes major ebook publishers, scientific-article publishers, and some other organizations, and which plans to eventually engage with the major browser vendors after they’ve developed their Web Publishing specifications more. We’ll see what comes of all that; it’s certainly a big need. Also related, over at the WHATWG, is ongoing work on DOM Range, DOM StaticRange, and DOM Selection.

I wish you luck with the WICG thread. If you find that it’s tough to drum up community/vendor enthusiasm at the WICG, it may be worth drafting a strawman of your concept as a more concrete and detailed specification (which, remember, must be backwards compatible with all already-valid HTML URL fragments). How much effort you should put into the strawman would depend on how likely you feel you might get buy-in from the community and/or browser vendors. It may be that your idea is before its time, and that it’ll be resurrected in a few years when a new vendor employee is enthusiastic about implementing the idea. Either way, good luck.

@nuragic
Copy link
Author

nuragic commented Mar 5, 2018

@js-choi

That’s just an example of an already-valid URL-fragment selector #namedSection that targets an HTML DOM node with id=namedSection.

Ok, thanks for the clarification!

I have another question: where do you think this proposal would fit? I mean, there's an existing spec that should be modified? Or I'd just need to create a new one?

Is it defined in the spec that browsers MUST scroll down to the element specified in the anchor?

@domenic domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Mar 6, 2018
@annevk
Copy link
Member

annevk commented Mar 7, 2018

@nuragic it fits here, per https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid.

@bokand
Copy link
Contributor

bokand commented Mar 20, 2019

For anyone interested, I've proposed a similar feature in WICG that would allow linking to a text snippet. For anyone interested in iterating on this proposal, please join us there!

@rniwa
Copy link

rniwa commented Mar 20, 2019

We need something more abstract than XPath or CSS selector if we wanted to allow addressing of an element within a shadow tree if we ever wanted that (I'm not saying we want or don't want such a feature).

@nuragic
Copy link
Author

nuragic commented Mar 20, 2019

Thanks for the suggestion @bokand! I'll read your proposal and hopefully I'll be able to give some feedback tomorrow. Happy that more people would be interested in this feature as well 🤗

@bokand
Copy link
Contributor

bokand commented Mar 20, 2019

We need something more abstract than XPath or CSS selector if we wanted to allow addressing of an element within a shadow tree if we ever wanted that (I'm not saying we want or don't want such a feature).

The Open Annotation community group has specified a number of different selectors for different contexts and cases. My hope is that we can spec something that's extensible, for other and future selectors as we find use cases, but start with limited-scope text quote selector rather than trying to solve every corner case. A simple text-search fragment would be hugely useful and serve as a good starting point for future iteration.

@nuragic
Copy link
Author

nuragic commented Oct 10, 2019

Closing this issue because there's already https://github.com/WICG/ScrollToTextFragment. Thanks @bokand for pushing it and everyone else for their feedback!

@nuragic nuragic closed this as completed Oct 10, 2019
@annevk
Copy link
Member

annevk commented Oct 10, 2019

We need to keep an issue here, but a new one is fine too, as this will eventually result in changes to HTML's navigate algorithm.

@annevk
Copy link
Member

annevk commented Oct 10, 2019

Ah, I guess that's #4868.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

7 participants