Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

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

share|improve this question
+1 I would love to know why this feature has not been implemented – Mike Pennington Aug 22 '12 at 10:54
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
up vote 38 down vote accepted

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.

share|improve this answer
I am really liking this implementation idea. Super clean. – John Rudy Feb 23 '10 at 20:43
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

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.

share|improve this answer
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
It won't break if you autogenerate a specific prefix (the answer ID itself?). – BalusC May 12 '10 at 23:01
Though currently most SE sites use HTML4 ( 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 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

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


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

[Link To][#target]    

  [1]: #target
share|improve this answer

Conjuring a new Markdown syntax for pre-specified anchor ids isn't the only option. 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.

share|improve this answer

You must log in to answer this question.

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