-
Notifications
You must be signed in to change notification settings - Fork 717
[selectors] New pseudo-class that matches the current URL fragment #6942
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
Comments
Here's a test page that demonstrates the |
Just to add a voice here, at present Perhaps an alternative would be to add a JS API to allow a page to set the current |
Afaict, the Selectors spec has always defined the So I would push back against this issue and say, are we really sure that it's not Web-compatible to do the right thing here? Because that seems like the best way forward. I'd rather not introduce a new |
Related: #5619 |
Just want to bump this — this issue is the one that constantly comes up in my practice, in sometimes it doesn't have any solution or workaround. Worst case: when a page has an anchor, and its content is dynamic in any way where the element won't exist initially. This would mean that we would be unable to share a link to this page where the The scrolling to the element can be worked around in various ways (most straightforward way — to have a mutation observer that waits for the element with the id matching the anchor to appear), but there is just no way to update the And the workarounds to have when navigating via pushState are far from convenient (replace the content, navigate to the anchor, so the I don't care much if the solution would be adding a new pseudo-class (though I agree that But this is a real issue that comes up constantly, and I really hope we would have a solution for this one day. |
Until someone gives me a use-case where The current approach almost says to me: «don’t touch browser's native I might believe that changing Shortly saying, use-cases where changing ✅ I solemnly claim to sign petition to fix |
Uh oh!
There was an error while loading. Please reload this page.
Original issue: WICG/navigation-api#162; /cc @jakearchibald @stephband.
Currently the
:target
pseudo-class is defined like so:HTML then defines this based on a target element pointer, which is updated at specific points when the scroll to the fragment algorithm is run during navigation/history traversal.
This approach of updating a pointer at specific points in time is not equivalent to "
:target
always matches the first document-tree element with an ID corresponding to the document's URL's fragment component". This is true in several regards:You can update a document's URL's fragment via
history.pushState(null, "", "#foo")
. (Or by using cursed magics.) This does not trigger "scroll to the fragment" and so does not update the target element.Inserting a new element does not trigger "scroll to the fragment". So if the current URL fragment is
#foo
, but no element currently has IDfoo
, then adding such an element will not cause that element to match:target
. Adding such an element can sometimes work, if you do so early in the document lifecycle before "scroll to a fragment" has completed. But usually it does not.There are various legacy-seeming string processing tricks going on that make the fragment/ID matching non-exact. E.g. special processing for
#top
(not sure if this impacts:target
), and how the algorithm first tries exact match and then tries to do an extra round of percent-decoding (so,#%66oo
will cause an element with IDfoo
to match, unless there is another element with ID%66oo
somewhere in the DOM).Similarly, there is a presumably-legacy affordance for
<a>
elements withname=""
attributes.@stephband has expressed that he much prefers the "always matches the first document-tree element with an ID corresponding to the document's URL's fragment component" model, mentioning specifically (1)-(2). ((3) and (4) were just things I noticed reviewing the algorithms, which maybe are worth considering while we're here.) And this use case makes sense to me.
I strongly suspect changing
:target
's behavior is not web-compatible, and further I think there are probably people who want the currently-specified target behavior. E.g. if you use:target
to highlight an element after the user scrolls to it via a fragment hyperlink, with some sort of fading-out flash, you might not want that fading-out flash effect for newly-inserted elements, even if they have an ID that happens to match the current URL fragment.But introducing a new pseudo-class, with the always-match semantics, might be worthwhile. My strawperson names are
:current-url-fragment
or:location-hash
.It's not clear to me how much of a problem this is. So far only @stephband has expressed this to be an issue for their applications. Lots of developers "liked" my corresponding tweet but nobody else showed up to the original issue on WICG/app-history or replied with comments. But I wanted to log this feature suggestion here since it does make sense to me.
The text was updated successfully, but these errors were encountered: