Support manual IDs

[mildsunrise]

As a feature, we could support PHP-extra style IDs for headers, tables, etc:

## How to use    {#usage}

<h2 id="usage">How to use</h2>

It was somehow proposed in #63, we should look into it.
That would solve the problem with autogenerated header IDs we discussed a while ago.

[mildsunrise]

Something like this:
https://bitbucket.org/kjdev/hoextdown

[blaenk]

I don't know if this was forgotten. I searched the issue tracker to see if someone has posted this before I requested it.

I too would really like this, I imagine for 4.0. It makes things more manageable when you have different sections with sub-sections that are named the same as other sections'. It's indispensable, since otherwise you can't really accomplish this. You could perhaps use a raw html header tag but then it'll get ignored by the table of contents generator.

[mildsunrise]

I would too! 😃 But it's the first time I look at implementing markers like this one and I'm not sure how to do it... Anyway, I'll really try to get it implemented in v4.

[blaenk]

Yes pleeeaaseee. I'm switching from Pandoc to Hoedown and I'm loving it so far but I'm trying to figure out what to do with my documents that use this feature, which are a lot surprisingly. It's not a big deal, but I figured I'd voice my request since 4.0 is in development.

You did mention hoedownext which already supports this, perhaps you can get an idea there. Personally I'm mainly interested in being able to specify id attributes, e.g. {#some-thing}, but some processors support a more generalized attribute syntax where you can specify many things, including classes, and some even (e.g. Pandoc) support key-value pairs, e.g. {#some-id .blue feature=yes}, that's probably overkill for now, but it indeed is a very nice feature because you can end up using markdown for most things that you wouldn't.

For example, I have a special CSS class for rendering paths and I could render them by doing something like:

`some/path/here`{.path}

Some processors like Pandoc have a specific subset of elements that you can use the attribute list on, since others might be trickier. I think Kramdown supports attribute lists on pretty much anything, which is definitely interesting and flexible, but probably difficult to implement or inefficient (for example you could even specify an attribute list for a preceding paragraph of text, a list item, etc.).

I mention this in case you're able and willing to design/implement this with an eye to a potential future in which this is supported.

[mildsunrise]

Yeah, this and inline footnotes are the two features I really love from Pandoc.

[RoyiAvital]

This would be a great new feature.
Any updates on that?

[Jmuccigr]

Consistency with pandoc would be nice.