135

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

Improve this question
13
  • 5
    +1 I would love to know why this feature has not been implemented Commented Aug 22, 2012 at 10:54
  • 12
    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. Commented May 2, 2013 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? Commented Nov 25, 2013 at 13:16
  • @Shog9 I would love this feature to be added. Commented Jan 21, 2017 at 8:15
  • 1
    This would be awesome. Especially for FAQ posts and stuff like this. Commented May 3, 2017 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. Commented Aug 29, 2017 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. Commented Aug 29, 2017 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. Commented Aug 29, 2017 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. Commented Aug 29, 2017 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. Commented Aug 29, 2017 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) Commented Aug 29, 2017 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. Commented Aug 29, 2017 at 17:59
  • Related: Linking to subheaders of a help center page. (These 2 requests are basically a subset of that one as well: Can we have anchors for the bullets in the [help/on-topic] list?, Add anchors to the how-to-ask and how-to-answer pages) Commented Dec 14, 2022 at 19:37

6 Answers 6

Reset to default
59
+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.

Improve this answer
6
  • 7
    I am really liking this implementation idea. Super clean. Commented Feb 23, 2010 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. Commented Jan 29, 2014 at 11:26
  • 2
    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. Commented Jan 25, 2018 at 15:46
  • I have a userscript that does this (but only for users who have it installed): stackapps.com/q/7994/9011 Commented Dec 12, 2019 at 12:31
  • 1
    How would duplicate heading strings be handled? I think the anchor names need to be unique, don't they? Commented Jun 8, 2020 at 5:14
  • @MarkAmery anchor links are an integral part of HTML and fails gracefully. If an anchor is removed/changed you have the current behavior - a link to the page. The same guidelines for links applies to anchor links. E. i. try not to hide links as actions. w3.org/WAI/tips/writing/#make-link-text-meaningful Commented Jan 10, 2021 at 19:40
16

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
Improve this answer
1
  • This would probably be more appropriate to support existing Markdown infrastructure. Commented Aug 29, 2017 at 16:14
13

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.

Improve this answer
4
  • I agree re id, for what it's worth. I should probably update the question to make that more clear. Commented Feb 2, 2010 at 5:47
  • 5
    It won't break if you autogenerate a specific prefix (the answer ID itself?). Commented May 12, 2010 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? Commented Apr 23, 2011 at 7:51
  • 2
    +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 Commented Aug 22, 2012 at 10:56
10

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 <a name=> 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.

Improve this answer
5

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?

Improve this answer
2

I'd like to supply my temporary solution for footnotes specifically, since it works with some numbers of newer browser versions and doesn't crash and burn otherwise.

If we want to supply a footnote, we can do something like:

Blah blah blah[<sup>1</sup>] Blah blah blah Blah blah blah Blah blah blah Blah blah blah --- 1. This is my footnote... (b3m2a1Footnote1) [<sup>1</sup>]: https://meta.stackexchange.com/questions/37894#:~:text=b3m2a1Footnote1 "This is my footnote..."

which renders like

Blah blah blah1

Blah blah blah
Blah blah blah
Blah blah blah
Blah blah blah

  1. This is my footnote... (b3m2a1Footnote1)

This is honestly pretty fragile and all depends on how well your browser does the search, but for single Q/A posts (most of what I find myself doing) it works well

Improve this answer
2
  • 1
    Nice idea, although I can't seem to get this to work on SO and your link above doesn't work for me either (Chrome). It does work (some of the time) if I manually enter the "same URL" in the browsers address bar though? Commented Sep 23, 2020 at 0:06
  • Three years later and Firefox still doesn't support Fragment Text Directives. It's unfortunate, but I think this method is a lost cause. Commented Nov 2, 2023 at 18:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.