3 ms·

The link here isn't exactly the right one - the same thing happened to me when I tried sharing this article previously as well (https://news.ycombinator.com/ite

The link here isn't exactly the right one - the same thing happened to me when I tried sharing this article previously as well (https://news.ycombinator.com/item?id=28933313 https://news.ycombinator.com/item?id=28933313). Either we both pasted the wrong URL or maybe HN trims off the hashtag part of the URL (with the #capital-as-power on the end of the URL). Anyways, the correct link is https://pluralistic.net/2021/10/20/vizio-vs-the-world/#capital-as-power https://pluralistic.net/2021/10/20/vizio-vs-the-world/#capit....

webmaven 5y ago
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).

webmaven 5y ago

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).