103

I admit this feature request is probably somewhat limited in useful scope, but I'm throwing it out there anyway. Inspired by this answer, and because I want to use it on this one, I'm requesting that name be supported on a tags in posts.

On very long answers, such as the closing/migration guidance answer, this would allow direct linking to the specific closure reason. This would then allow us, when someone asks why a question was closed, to link directly to the appropriate reason and description thereof.

I recognize the limited scope of this, however, I have seen other long answers that could stand to have that kind of "deep" linking ability as well.

(The original incarnation of this post had either name or id, but preferenced name. Per Koper's answer, which I agree with, I took out the idea of supporting id, because Koper's right -- too dangerous.)

  • 4
    +1 I would love to know why this feature has not been implemented – Mike Pennington Aug 22 '12 at 10:54
  • 11
    3yrs and this has not been implemented? Github allows this and it's great for writing documentation. I should point out that PHP tag on Stack Overflow has many reference posts which are very long. Allowing anchors will not only simplify the linking process to fine tune a dupe to the relevant section it also allows for a Table of Contents to be made as well for easier navigation. Please add support for this. – cryptic ツ May 2 '13 at 23:58
  • What about the possibility that a user links to a point that has no name defined? Would this be prone to generating text/code inconveniently messy? – sancho.s Nov 25 '13 at 13:16
  • @Shog9 I would love this feature to be added. – Buffer Over Read Jan 21 '17 at 8:15
  • This would be awesome. Especially for FAQ posts and stuff like this. – Jason C May 3 '17 at 6:57
  • Now that Documentation is being sunset this is extremely relevant again - it would be extremely helpful (especially on Code Review) to be able to create canonical links to a specific point of a very long answer, especially if many of the points are large and of particular relevance. – 410_Gone Aug 29 '17 at 16:44
  • @EBrown: I too would like anchor links. The main problem is that we need to invent a new way to do this in Markdown. For several possibilities, see a discussion on CommonMark's forum. Turning empty link definitions into anchors would be another possibility. But since answers share the page, there'd need be a functional spec dealing with differentiating anchors if, by chance, two authors use the same anchor name. – Jon Ericson Aug 29 '17 at 16:58
  • @JonEricson I actually proposed a variant of the URL syntax on the Code Review site (well before seeing this question, or that CommonMark discussion), if the first character after the opening parenthesis is a pound-sign (#) and it's alpha-num + - only, then make it an Anchor tag. This fits right in with the current URL syntax, and even allows you to define them on non-heading elements as well. – 410_Gone Aug 29 '17 at 17:02
  • @JonEricson if the post ID is part of the URL then the same-anchor-name problem is solved IMO. I think the biggest challenge is dealing with the revision system, where a link may exist in rev.2 but be gone in rev.3. – Mathieu Guindon Aug 29 '17 at 17:06
  • @Meta'sMug: True. But that introduces a usability difficulty. It's hard/impossible to predict the PostId while writing the post if you want to use internal links. Then we'd need to make it clear that an anchor exists and what the name is. As always with Markdown changes, we're somewhat reluctant to break ground inventing syntax. – Jon Ericson Aug 29 '17 at 17:23
  • @JonEricson why would syntax need to change? if I do ### Some Heading then it's the renderer's job to come up with an ID, not the user's. I think it's more about changing how the existing syntax gets rendered, than changing the syntax itself - like the currently top-voted answer suggests. The preview box wouldn't need to implement it (navigating previewed links would navigate away from the post being written anyway) – Mathieu Guindon Aug 29 '17 at 17:51
  • 1
    @Meta'sMug: Hmmm... Seems like the more we rely on the system to make the links work, the more likely a GUID system would be better than letting the user specify any part of the ID. – Jon Ericson Aug 29 '17 at 17:59
47
+50

I would like to see this so links to long posts can go directly to the relevant bit. Especially useful for the FAQ, Glossary, and those posts with lots of general information.

A simple implementation would be to automatically convert titles and headings into named anchors. If you want to have links inside your post, just use a heading.

This then wouldn't require odd formatting, a special case, and would still produce readable markdown (one of the main features of markdown is that markdown source is human readable).

Here's the title anchor (Title)

This would be one anchor (Heading 1)

This would be another anchor (Heading 2)

Here's the third anchor (Heading 3)

And here's the fourth anchor (Heading 4)

The fourth anchor is nearly the same size, weight, emphasis and font as normal text, so one can 'hide' anchors in the text if they don't want a noticeable heading. It still has to be on its own line, but it's better than nothing.

Further, links to them would be very nice - they'd have the heading in them.

The parser may need to replace the spaces with underscores _, remove invalid characters and add a monotonic number (so the page doesn't end up with multiple anchors of the same name) but overall it appears to be a relatively easy thing to implement, and will, as a bonus, be backwards compatible with existing markdown files - converting any existing headings into anchors simply by re-parsing them into HTML.

  • 6
    I am really liking this implementation idea. Super clean. – John Rudy Feb 23 '10 at 20:43
  • 2
    What happens when the answer gets edited later to change the title, or add another title earlier in the post, or change it from a h1 to a h2? It seems to me that you'd want to allow the answer author to specify ids in order to let them sensibly choose whether to preserve or break anchor links on future editing, but automatically prefix the id of the element with the answer id to avoid clashes with other ids on the page. – Mark Amery Jan 29 '14 at 11:26
  • It would be nice to link down to footnotes too, not just for hitting headers. I was just going to suggest that a guy thoroughly answering a question do that and I could have sworn I'd seen it before, but I think it was just in big CW style questions on meta. – Peter Turner Jan 25 '18 at 15:46
13

I upvoted it as well. I am wondering if a markdown for named anchors will be more helpful instead of just HTML?

E.g.:

[Link From ver 1][1]
[Link From ver 2](#target)
.
.

[Link To][#target]    
.
.

  [1]: #target
  • This would probably be more appropriate to support existing Markdown infrastructure. – 410_Gone Aug 29 '17 at 16:14
10

I upvoted it, but don't allow ids to be specified. It will break the validation of the page even more if someone chooses an id already in use, and especially, it will break javascript features too.

I see nothing wrong with allowing name. Honestly you will most likely be the only person using it, but still, it won't hurt and it should be easy to implement.

  • I agree re id, for what it's worth. I should probably update the question to make that more clear. – John Rudy Feb 2 '10 at 5:47
  • 3
    It won't break if you autogenerate a specific prefix (the answer ID itself?). – BalusC May 12 '10 at 23:01
  • 1
    Though currently most SE sites use HTML4 (stackexchange.com itself is not), others might use the data in HTML5. And who knows: some day SE might be all HTML5 too. For HTML5, <a name=...> is obsolete, and even if somehow present then it must be unique, and must not match any of the ids? – Arjan Apr 23 '11 at 7:51
  • 1
    +1 Stack Exchange could automagically hash ids into unique values, per answer... this would solve the aforementioned validation problem... as it stands, they are already mangling div ids, as shown in this answer – Mike Pennington Aug 22 '12 at 10:56
7

Conjuring a new Markdown syntax for pre-specified anchor ids isn't the only option.

 http://stackoverflow.com/q/10101010#~the name of your view

Fragment identifiers for text searching

There isn't yet a standard for HTML. But other document types already allow fragment identifiers for searching/deep linking. PDF for instance #search=text, text/plain at least #line=120,130

It puts web consumers in advantage and unburdens document authors, if pinpointing to web pages is feasible just per the URL (as also it should be).

To give a few implementation and syntax examples:

  • #findhash (userscript) makes the existence of anchors redundant. In absence of the specified DOM name= or id= it just searches for text content.

  • #~search+word (userscript) is something I wrote. It adds a ~ prefix for differentiation to plain anchor ids. And ~ looks like a search thingy, or at least reminiscent to Perls regex search =~ operator.

  • #!s!design fragment search provides a syntax similar to now common #!hashbangs.

  • cssFragID is a more official propasal, but seems unfit for SE. While the DOM traversal approach is on-topic for SO; our questions/answers commonly shift (voting), nevermind the frequently evolving layout. So would be more brittle than text search anchors.

  • Or let's make something up: #/<b>.*Zalgo/s

In any case it's just a few lines of jQuery. Would benefit external referencing. And we wouldn't need heaps of synthetic or manually crafted anchor ids.

Usually e.g. Stackoverflow Q&As are technically succint, where #answer-12345 anchors suffice.
But we also have quite a few very detailed and authoritative reference answers; naturally more lengthy. And providing URL #search-FI support would entice aimed linking to those.

Also if SE decides on a reasonable syntax, one could hope for this catching on; even if just implemented on a per-website basis in lieu of WHATWG interest.

2

I don't disagree with the accepted answer, but I'm answering because it's recommended as a way to draw attention to a feature request.

As of this post, the question is 9 years old with 98 upvotes - yet there is still no status tag, or indication of whether it will be implemented.

Linking to "parts" of an answer would be extremely beneficial - it would allow us to reference long answers for more specific questions without reposting the information.

MediaWiki (the open-source version of Wikipedia) has this ability and I've used it to great effect in a professional setting. It allows a single source of information to be "replicated" in other parts of the site. Any future changes to the source are automatically reflected everywhere it's referenced. Linking isn't quite as good, but it's still a major step in the right direction. Can we get a status or response?

You must log in to answer this question.

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