Right now there is no markdown anchor syntax. Simplified anchor syntax would be handy when you want to make a hypertext fiction (or a more complex documentation). Current approach is to just type in the html code for anchors. For example in this half baked idea post.

According to http://stackoverflow.com/questions/484719/html-anchors-with-name-or-id anchor is defined by html #id . Thus:

Perhaps it can be a modified version of the link syntax

[anchorName] {#anchorName}

Alternatively you could restrict it to headers like

header text here
========================= {#anchorName}

or

#  header text here # {#anchorName}

Elsewhere in the document you can create a jump point to the anchor like

[test](#anchorName)

---

Edit: Modified to fit what other people are suggesting for generic attribute syntax

I would like to add that Markdown is used often for one-page webpages, where anchor links become very important, if you want to send out detailed links. So it would be great of Standard Markdown to make the common case nicer.

This is a much needed feature that only exist in very few markdown implementation.

I agree and propose that this should be seen in light of the issue of a generic attribute syntax. Therefore, # Header here {#anchorName} might be preferred (as already implemented in Pandoc).

This would be a very useful addition for authors. But there are some difficulties in implentation. Notably, duplicate ids in the DOM might cause problems. I also prefer the Markdown Extra syntax:

# header text here {#anchorName}

I think that looks much better jericson so good idea, if it allows for jumping to that anchor.

Notably, duplicate ids in the DOM might cause problems.

No, duplicate IDs make your document non-conforming, but don't actually cause any problems. (At least, no problems with the browser. If you've got a script that thinks an id is a unique identifier, it might get the wrong element when it tries to retrieve an element by ID, but that's it.)

No, duplicate IDs make your document non-conforming, but don't actually cause any problems.

Sure. But it seems like a bad idea to introduce a feature that doesn't work reliably. As with Wikipedia, the big concern is to allow unambiguous links to sections of a document. There is likely no perfect solution, however.

This has enough uses and adds little enough in the way of syntactic complexity that I believe its inclusion in core CommonMark is reasonable.

I tend towards making it a modified form of the link syntax, since anchor links are links, and because it would allow anchoring to any location in a document, not just to a limited number of elements. (I believe that Markdown Extra doesn't allow arbitrary placement of anchor links, though I may be wrong.) That said, I wouldn't be against a standard syntax that allows the setting of arbitrary attributes on an inline or block element, which would serve the same purpose but allow greater flexibility.

That said, in the end I have the feeling that this is going to be deemed "extension material" and left for other people to implement.

For anchors, this is starting to come towards the proposed standard for a generic attribute syntax via {} for example:

 ![altText](myImage.png){#id .myClass width=40 height=50}

So in the case of anchors, it would just be a case of setting the #id tag of an element. E.g.

 []{#id}
 [Optional Anchor Text]{#id}
 # Header with anchor # {#id}
 Header with anchor
 =================== {#id}

I modified my first post to fit this development

Consistent attribute syntax

Eventually, the spec should specify a consistent way to add attributes to at least the following elements: headers, images, code blocks (and maybe even tables, block quotes and inline code and quotes). The most important attributes are certainly id (to enable links to those elements) and class (for styling) which might have shortcuts like #myId and .myClass but other attributes (like width and height for images) are useful as well. Stmd currently specifies info strings for code blocks like thi…