3 ms·

I definitely submitted the URL with the hash-mark and fragment[0], so HN must strip it off. [0] https://en.wikipedia.org/wiki/URI_fragment https://en.wikipedia

I definitely submitted the URL with the hash-mark and fragment[0], so HN must strip it off. [0] https://en.wikipedia.org/wiki/URI_fragment https://en.wikipedia.org/wiki/URI_fragment

dang 5y ago
Yes, that's what happened. Sorry! I've put it back and will try to prevent this from happening again.
- 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 ago
    We'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).

I definitely submitted the URL with the hash-mark and fragment[0], so HN must strip it off. [0] https://en.wikipedia.org/wiki/URI_fragment https://en.wikipedia.org/wiki/URI_fragment

dang 5y ago

Yes, that's what happened. Sorry! I've put it back and will try to prevent this from happening again.

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 ago
  We'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).