- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Sat, 21 Jan 2023 15:38:29 +0000
- To: public-css-archive@w3.org
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 `:target` would work. 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 `:target` without adding a new history entry. And the workarounds to have when navigating via pushState are far from convenient (replace the content, navigate to the anchor, so the `:target` would trigger, replaceState with the new URL, replacing the entry with the anchor). I don't care much if the solution would be adding a new pseudo-class (though I agree that `:target` should just work, and `:target-no-really` is just weird), adding something like an opt-in to the `pushState`/`replaceState` where it would apply the target to the given anchor (this way the initial load issue could be potentially worked around via calling `replaceState`), or maybe just adding a method that invalidates the old `:target` and applies the new one. But this is a real issue that comes up constantly, and I really hope we would have a solution for this one day. -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6942#issuecomment-1399274651 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 21 January 2023 15:38:30 UTC