13

I've noticed that link-ids are not rewritten. I would much prefer it if they were.

For instance, lets say I'm on this page. And, let's say I want to link to a specific answer like #3346729 by @Eric. It would be nice if an inserted link on the page to that question would get rewritten to be href="#3346729". This would prevent the need for my browser to reload the page. I would save a lot of time, and with this extra time I could help even more people.

This is of course only referencing the html to be rendered. I don't care at all about what sits in the SO DB... Though personally I wouldn't want to fix my internal linking to make assumptions about the transport.. That seems silly, but it is not my business. Wikipedia doesn't permit this because it is a bad idea, that's why Wikipedia is one step ahead with the [link generator], and even has [otherprojects:linkgenerators] accessible that make no assumptions about where the questions/answers are currently sitting. Even perlmonks had link generators some 10 years ago, [rt:num], and[id:node].

UPDATE

If you change the display links to be only relative to the current page, you can no longer copy/paste them so that they can be used elsewhere, such as in another SO posting, or another website. – Robert Harvey 1 hour ago

So Dr. Harvey has a point. I looked into how Wikipedia does this, because they're a few steps ahead of Stack Overflow, and apparently all you have to do is not specify the "comment" number.

If you click on this link it will not rerender the page. http://meta.stackexchange.com/questions/58645/updated-question-plz-reread-please-make-links-to-other-answers-in-the-same-qu#58685

or this link, '#58685`

If however, you click on this link it will http://meta.stackexchange.com/questions/58645/updated-question-plz-reread-please-make-links-to-other-answers-in-the-same-qu/58685#58685

So what SO is doing is rendering a different canonical url entirely for the comment at /58685 even though that page is most probably the same, how very dirty.

Update AGAIN

Had to change the links because they changed when I updated the title (another SO bug I guess)

Improve this question
12
  • 3
    I think the reason this is not done is that there can be multiple pages of answers, but I'd like this if it were possible.
    – mmyers
    Commented Jul 27, 2010 at 18:55
  • 2
    If they could migrate the platform to PHP they could probably do it in a VIEW.
    – Evan Carroll
    Commented Jul 27, 2010 at 18:58
  • 11
    Sure, and if you tore down your two-story house and built a one-story to replace it, you wouldn't have to walk upstairs. :P
    – user102937
    Commented Jul 27, 2010 at 20:40
  • 8
    Evan has found the perfect way to get reputation: he's now making proposals that have some sense, but he writes them in a very bad way, thus getting downvotes. Then someone edits it and he suddenly gets a lot of sympathy upvotes.
    – Andreas Bonini
    Commented Jul 27, 2010 at 20:51
  • @balpha if you're going to edit my question at least do it fully and fix what you break. As I said, unlike Wikipedia SO doesn't update internal links when you change the title. (So you'll have to update any internal links on Dr. Gonzo's post too)
    – Evan Carroll
    Commented Jul 28, 2010 at 16:00
  • -1 for that title (thank you balpha) -- the links are still valid @Evan, the title portion is completely aesthetic (http://meta.stackexchange.com/questions/58645/58685#58685 also works)
    – badp
    Commented Jul 28, 2010 at 16:02
  • 1
    right, but if you're on http://meta.stackexchange.com/questions/58645_foo and you internal link to http://meta.stackexchange.com/questions/58645_foo#58685 the page doesn't get re-rendered, if however you internal link to http://meta.stackexchange.com/questions/58645_bar#58685 the page is forced to re-render.
    – Evan Carroll
    Commented Jul 28, 2010 at 16:09
  • Related
    – Michael Mrozek
    Commented Jul 28, 2010 at 17:30
  • 1
    @Evan: Changing the title of a linked page does not break the link. SO filters the title out of the link when routing pages.
    – user102937
    Commented Jul 28, 2010 at 20:27
  • @Robert I din't say it broke the link. I said, in my example, it will force your browser to issue another request and rerender the page. i have a very specific example if you would read it just two comments up.
    – Evan Carroll
    Commented Jul 28, 2010 at 20:28
  • I vow for adding a jquery with a regexp on every link that's on the same webpage that will make them all just navigate-to when clicked, rather than reload, per this issue.
    – cregox
    Commented Jun 16, 2011 at 20:09
  • +1 for this. Even better solution is give both permalink and anchor in share button. And permalink should be selected by default. So that users can choose themselves.
    – Himanshu
    Commented Apr 19, 2014 at 5:27

3 Answers 3

Reset to default
3
  1. The link "button" actually is a permalink button. Permalinks need to be future ready (or they wouldn't be permalinks) and cannot just rely on anchors. That is why the post ID needs to be built into the URL in both the URL proper and the anchor.
  2. Permalinks include human readable question titles for courtesy, but the software ignores that portion. The following links are all valid and all point to the same "target":
  3. It is not necessary to reload the page when clicking on link; a pop up box could appear with the link, pretty much in the same fashion as Area51 does with referral links. I think this idea still has some merits, including:
    • Taking you to the permalink is probably the only reliable, non-evil way to update your location bar.
    • This action requires no javascript (although the fading effect and much else on this site does).
    • Taking you to the URL allows you to experience what others will when they'll click on the link, which is useful to confirm you are linking to what you think you are linking.
    • This can be used to refresh without being sent to the top of the page by your browser.
    • This behaves correctly for ctrl-clicks, shift-clicks, command-clicks and option-clicks for whatever settings the user may have.
Improve this answer
6
  • The idea is just to render http://meta.stackexchange.com/questions/58645/58685#58685, as http://meta.stackexchange.com/questions/58645#58685 if you're on a page that already has #58685, this isn't difficult and I'm not sure what your whole rant is addressing.
    – Evan Carroll
    Commented Jul 28, 2010 at 16:36
  • It's not a rant. It's my explaination that http://meta.stackexchange.com/questions/58645#58685 just cannot be a permalink, @Evan.
    – badp
    Commented Jul 28, 2010 at 16:58
  • 4
    Except one thing you're wrong. It doesn't need to be a permalink. You know what answers are on the page you're rendering. You know what answers the links are pointing to. If the link is pointing to an answer on the page being rendered, rewrite it to a non-permalink. render_link( link_text, array_answerids_on_page ); etc.
    – Evan Carroll
    Commented Jul 28, 2010 at 17:49
  • It is a permalink. That's the primary purpose. Have you read point 3?
    – badp
    Commented Jul 28, 2010 at 18:47
  • 1
    In fact, you can use an even shorter permalink: meta.stackexchange.com/q/58685
    – Tobias Kienzler
    Commented Aug 26, 2010 at 14:08
  • How about when clicking on a link to another answer on the same question?
    – cregox
    Commented Jun 16, 2011 at 20:09
2

Stack Exchange/Stack Overflow already changes hyperlinks all the time. They just need to check, and if it's an answer on the same page, then modify it to be the in-page type. The only hard part is dealing with pagination. I'll leave that up to the web gurus.

Improve this answer
4
  • Great idea! There's also the issue of people trying to copy the link, to which I think a jquery approach might do it better.
    – cregox
    Commented Jun 16, 2011 at 20:27
  • @Cawas, yes, if jquery can override how copy works, then that would be great. Just have it translate it back to the type of link that needs to be copied.
    – Lance Roberts
    Commented Jun 16, 2011 at 20:28
  • No, the idea would be using jquery for the scrolling part only, and leaving the link intact.
    – cregox
    Commented Jun 16, 2011 at 20:29
  • @Cawas, well that would probably work fine also, refreshing the page is definitely a slowdown.
    – Lance Roberts
    Commented Jun 16, 2011 at 20:33
1

In addition to the pagination issue that has already been mentioned, it will also break the links in the following locations:

  • The revisions page
  • The edit page's preview pane (2K+ required)
  • Maybe the RSS feeds? (I'm not sure about that one; I don't use Stack*'s RSS feeds.)

Might it also have some impact on StackAPI apps? (Not sure there either; haven't even looked at the API.) I'm sure there are other places where there might be impact as well ... I just can't think of them off the top of my head.

So basically, while it's a pretty decent idea, there are a lot of ramifications I think you're missing.

Improve this answer
7
  • I'm not sure how you come to these conclusions... You must have made some fairly silly assumptions about a specific implementation, please explain.
    – Evan Carroll
    Commented Jul 27, 2010 at 21:57
  • When on the revisions or edit pages, you don't have those anchors available anymore. So clicking them breaks the link. I'm assuming you want, when posting, the link to be rewritten. Now if you only want it on view/display, then that's a different story. However, view/display is considerably more common than edit/post, and we're talking about a potentially large search/replace, thus I would personally choose to develop such a solution at edit/post time. For view/display time, you could always write a GreaseMonkey plugin to do such for you, though.
    – John Rudy
    Commented Jul 27, 2010 at 22:02
  • 2
    Who said anything about the edit pages? Or, revision pages for that matter. I just said I don't want to have to re-render the same page if the link is targeting an internal part of the already rendered page. I don't need the link to be rewritten at all. You can conceivably fix most of the problems with GreaseMonkey, but that doesn't make it less of a bug here, or less worthy feature request.
    – Evan Carroll
    Commented Jul 27, 2010 at 22:08
  • 1
    "It would be nice if an inserted link on the page to that question would get rewritten to be href="#3346729"." -- Original post. That's where "rewritten" comes from. If you rewrite on view/display, then that solves the breaking of those links on edit/revision pages (where they are rendered, and may still be of use). However, again, view/display is very common -- rewriting every post to do that, with the pagination issue as well, is not a trivial task for the server. It's a good suggestion, but a very tricky implementation.
    – John Rudy
    Commented Jul 28, 2010 at 13:51
  • 1
    If you change the display links to be only relative to the current page, you can no longer copy/paste them so that they can be used elsewhere, such as in another SO posting, or another website.
    – user102937
    Commented Jul 28, 2010 at 14:17
  • @Robert Harvey, I'll update the question with more information.
    – Evan Carroll
    Commented Jul 28, 2010 at 15:45
  • 1
    @Robert Harvey: “you can no longer copy/paste them so that they can be used elsewhere” — It works just fine in IE, Opera and Firefox. No idea why you think you can’t do this.
    – Timwi
    Commented Aug 22, 2010 at 23:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .