-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
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 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. |
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. |
Thanks so much for your feedback! 🙌 Great points. The 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:
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.
This proposal would have exactly the same gotchas as the current behavior, right? I mean, people could publish/share e.g. 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 And finally thanks for suggesting to post this in the WICG, will do so. |
@nuragic: You’re probably referring to the 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. |
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? |
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! |
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). |
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 🤗 |
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. |
Closing this issue because there's already https://github.com/WICG/ScrollToTextFragment. Thanks @bokand for pushing it and everyone else for their feedback! |
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. |
Ah, I guess that's #4868. |
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:
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!
The text was updated successfully, but these errors were encountered: