5 ms·

This seems like an odd feature, with more downsides than positives. Sure: long, messy URLs seem ugly; but, anchor tags and query parameters are often integral t

This seems like an odd feature, with more downsides than positives. Sure: long, messy URLs seem ugly; but, anchor tags and query parameters are often integral to display the desired state of a certain page. Anchor tags especially. Also, how does it determine which parameters are critical to keep in? In the example, `ie` and `node` are retained, but `smid` is stripped. Obviously, `node` is important`, but `smid` may also be, whereas `ie` seems superfluous.

Osiris 9y ago
Exactly. When I share links, I always test a link (load the link in a private window) after stripping out the extra URL info before sharing it. I'm not sure how a browser would do that automatically.
- labster 9y ago
  Actually your process seems pretty easy to automate. Reload a page until you get the minimum set needed to reproduce the current DOM.
  - ikeboy 9y ago
    Except many pages have unique data on each load
  - Osiris 9y ago
    If that's what Chrome is doing, verifying that the shortened URL produces the same DOM, then I wouldn't have a problem with that.
  - dullgiulio 9y ago
    That has exponential complexity, is network-bound (slow) and still doesn't handle many cases (for example a "current DOM" where all relative links and images are broken).
    - bluepnume 9y ago
      Should be O(n) unless you're trying to optimize for every single permutation of query param, right? I'd assume the majority of the time the individual params would be independent from one another. Plus you'd only need to do it once in a while for any given base url and persist the result.
    - labster 9y ago
      Compared to GGP's approach of having a human do it, this is still fast. Also not sure why you'd want to share a link to a page where all the images and links are broken in the first place.
  - yjftsjthsd-h 9y ago
    With JavaScript in play, even reloading the exact same page might yield a different DOM
    - colejohnson66 9y ago
      Or corporate websites where something as simple as looking at my schedule has a “query run” time
- illnewsthat 9y ago
  I do the same thing. That being said, a huge majority of users wouldn't take these extra steps.
koboll 9y ago
Agreed. Why is this necessary? The only possible endgame here seems like sites abandoning query params in favor of baking that information directly into the URL, which is a worse situation all around.
kodablah 9y ago
After some investigation, it appears to use the link rel=canonical head element that the search engine uses [0]. So it doesn't seem that nefarious since it's opt-in. 0 - https://support.google.com/webmasters/answer/139066?hl=en https://support.google.com/webmasters/answer/139066?hl=en
- skymt 9y ago
  I can confirm this after a look at the source. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebDocument.cpp?l=286 https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...
- kevin_b_er 9y ago
  Will this mean the canonical links will start to disappear from pages? I doubt amazon, for one, will want to lose their tracking markers from pressing share.
  - kodablah 9y ago
    I hope so. I don't appreciate that they were floated for SEO and are now used for an alternative purpose. They don't even mention it on the page I linked. What I wonder is if the other forms of letting Google know the SEO-canonical URLs are also applied to Share-Link-canonical URLs (e.g. in the sitemap). I suspect not based on the sibling poster's source link. So the right answer seems to be not to use the head element if you don't want Google taking it off when sharing. All web devs know how to use JS to perform non-history-changing URL changes if we really wanted to cull the query parameters. We don't need their help.
deleted 9y ago
[deleted]

Osiris 9y ago

Exactly. When I share links, I always test a link (load the link in a private window) after stripping out the extra URL info before sharing it. I'm not sure how a browser would do that automatically.

labster 9y ago
Actually your process seems pretty easy to automate. Reload a page until you get the minimum set needed to reproduce the current DOM.
- ikeboy 9y ago
  Except many pages have unique data on each load
- Osiris 9y ago
  If that's what Chrome is doing, verifying that the shortened URL produces the same DOM, then I wouldn't have a problem with that.
- dullgiulio 9y ago
  That has exponential complexity, is network-bound (slow) and still doesn't handle many cases (for example a "current DOM" where all relative links and images are broken).
  - bluepnume 9y ago
    Should be O(n) unless you're trying to optimize for every single permutation of query param, right? I'd assume the majority of the time the individual params would be independent from one another. Plus you'd only need to do it once in a while for any given base url and persist the result.
  - labster 9y ago
    Compared to GGP's approach of having a human do it, this is still fast. Also not sure why you'd want to share a link to a page where all the images and links are broken in the first place.
- yjftsjthsd-h 9y ago
  With JavaScript in play, even reloading the exact same page might yield a different DOM
  - colejohnson66 9y ago
    Or corporate websites where something as simple as looking at my schedule has a “query run” time
illnewsthat 9y ago
I do the same thing. That being said, a huge majority of users wouldn't take these extra steps.

koboll 9y ago

Agreed. Why is this necessary? The only possible endgame here seems like sites abandoning query params in favor of baking that information directly into the URL, which is a worse situation all around.

kodablah 9y ago

After some investigation, it appears to use the link rel=canonical head element that the search engine uses [0]. So it doesn't seem that nefarious since it's opt-in. 0 - https://support.google.com/webmasters/answer/139066?hl=en https://support.google.com/webmasters/answer/139066?hl=en

skymt 9y ago
I can confirm this after a look at the source. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebDocument.cpp?l=286 https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...
kevin_b_er 9y ago
Will this mean the canonical links will start to disappear from pages? I doubt amazon, for one, will want to lose their tracking markers from pressing share.
- kodablah 9y ago
  I hope so. I don't appreciate that they were floated for SEO and are now used for an alternative purpose. They don't even mention it on the page I linked. What I wonder is if the other forms of letting Google know the SEO-canonical URLs are also applied to Share-Link-canonical URLs (e.g. in the sitemap). I suspect not based on the sibling poster's source link. So the right answer seems to be not to use the head element if you don't want Google taking it off when sharing. All web devs know how to use JS to perform non-history-changing URL changes if we really wanted to cull the query parameters. We don't need their help.

deleted 9y ago

[deleted]