3 ms·
Given that there are sites that use fragment identifiers to encode state, and users may be including fragments mistakenly (eg. click a link in a Wikipedia page'
by webmaven 5y ago
Given that there are sites that use fragment identifiers to encode state, and users may be including fragments mistakenly (eg. click a link in a Wikipedia page's TOC, scroll to the top, share link), figuring out what to do with some random URL submission that includes a fragment isn't straightforward.
In THEORY, when the fragment is (semantically?) significant, the site could dynamically alter the link rel="canonical" value to include the fragment such that you could check whether to keep it or not, but in practice I think that canonical links are intended for web crawler deduplication and so nearly always strip fragments off.
- dang 5y agoWe're indeed replacing links with canonical URLs now, as of maybe a month ago. But we were stripping anchors from URLs even before that, with a list of exempted sites. I've added pluralistic.net to that list now. If there's a better way to do it, I'm interested.
- webmaven 5y ago> If there's a better way to do it, I'm interested. About the only thing I could suggest would be to add a checkbox to the submission form that controlled fragment-preserving vs stripping, but you would probably need to add a review queue to double check it wasn't being abused (not that abuse is a particularly attractive target, in this case), and I am unsure whether the minor additional code and UI complexity is worth it vs. the ad-hoc process you have now. A second possible approach would be to invert that suggestion and simply add a review queue to check whether a removed fragment should have been preserved instead (ordering or filtering the queue by the rank of the submission rather than chronological order, for sanity purposes).