Enhancement request: option to generate labels/IDs using random data

[larrykollar]

I've run into issues, especially when publishing collections, where a second-level heading is not unique across an entire document—for example, ## Chapter 1 might appear two (or more) times. So those headings end up with duplicate id attributes, and EPUBCHECK has a hissy-fit about it. For that matter, so does the parser in FOP, which I use to transform the HTML to PDF.

A —randomlabels option might generate strings like id="fdi4nq0h", an 8-character string of random lower-case letters and numbers, and would solve the issue of duplicate header content.

[fletcher]

Thanks for the suggestion.

I'm not sure it's that simple, though...

1. Using random id's everywhere would break the ability to link to headers
2. Which means that it could only be applied to headers that are not used for internal linking
3. Which means that the label used for a header cannot be determined until after the entire document has been processed -- this would cause undesirable behavior in certain use cases
4. But even then, something like this would be missed and therefore would be broken by this strategy -- <a href="#topic">link</a>
5. Additionally, this would require some potentially complicated restructuring to the program, as the current assumption is that the id attribute is predictable based only off the text defining the header without any knowledge of the rest of the document.

A possibility, that could potentially still require fairly involved rewrites, could be:

1. Enabling this feature kills all id attributes except where manually specified (thereby breaking any internal links)
2. The only thing automatic id attributes would be useful for, then, would be a {{TOC}}
3. It then becomes somewhat arbitrary as to what the actual id attributes are -- random string of letters vs digits, sequential numbers, sequential strings, etc.

Thoughts?

[dgreen]

Just thinking along with others on this... Would an option to prepend or append its location in the outline structure help some? 1.1_Text # first h2 under first h1 2.1_Text # first h2 under second h1 2.1.1_Text # first h3 under first h2 of second h1 It stops the collisions and it is predictable for writing in internal links although it would be more painful than before (and thus should only be an option).

…

On 28 Sep 2018, at 19:32, Fletcher T. Penney wrote: Thanks for the suggestion. I'm not sure it's that simple, though... 1. Using random id's everywhere would break the ability to link to headers 2. Which means that it could only be applied to headers that are not used for internal linking 3. Which means that the label used for a header cannot be determined until *after* the entire document has been processed -- this would cause undesirable behavior in certain use cases 4. But even then, something like this would be missed and therefore would be broken by this strategy -- `<a href="#topic">link</a>` 5. Additionally, this would require some potentially complicated restructuring to the program, as the current assumption is that the id attribute is predictable based only off the text defining the header without any knowledge of the rest of the document. A possibility, that could potentially still require fairly involved rewrites, could be: 1. Enabling this feature kills all id attributes except where manually specified (thereby breaking any internal links) 2. The only thing automatic id attributes would be useful for, then, would be a `{{TOC}}` 3. It then becomes somewhat arbitrary as to what the actual id attributes are -- random string of letters vs digits, sequential numbers, sequential strings, etc. Thoughts? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #157 (comment)

[larrykollar]

1. Using random id's everywhere would break the ability to link to headers

Yipe, good point!

2. The only thing automatic id attributes would be useful for, then, would be a {{TOC}}

To be honest, I was being myopic. I use MMD for fiction, which doesn't generally use cross-refs, and I'd only need IDs for the TOC. I use LwDITA's Markdown (GFM with a couple extensions) for non-fiction.

Looking through the MMD documentation, I thought ## chapter title [chapid] should work to specify an ID, but a quick test proved me wrong. If I misunderstood what the square brackets are supposed to do, could I propose using the LwDITA way, ## topic title {#topicid} to specify an ID instead? Fiction all too often becomes reality these days, and it might be useful to move one to another. :-P

So maybe we close this issue and I open a new issue to request a way to specify an ID?

P.S. Supporting the YAML --- fences around the metadata really made my life easier, as I have a Jekyll-based blog. Thanks for doing that!

[fletcher]

## chapter title [chapid] should work to specify an ID

It does.

[fletcher]

Would an option to prepend or append its location in the outline
structure help some?

1.1_Text # first h2 under first h1
2.1_Text # first h2 under second h1
2.1.1_Text # first h3 under first h2 of second h1

It stops the collisions and it is predictable for writing in internal
links although it would be more painful than before (and thus should
only be an option).

I've thought about variations on this, but don't love it.

1. It's predictable enough that people would try to use it, but then as soon as the structure changes links no longer work properly.

2. There would be collisions between sections when pieces are processed via MultiMarkdown separately and then combined (similar to what happens to footnotes on a blog page made up of multiple individual stories.)

I would likely do something similar to the random footnotes option that creates pseudo-random numbers. But I'm not 100% convinced yet.

[larrykollar]

OK, I've verified the square brackets method of specifying an ID works… as long as you don't have trailing spaces. That's good enough for my purposes.

[fletcher]

What do you mean about trailing spaces? Can you give an example of what doesn't work for you?

[fletcher]

(Reopening because there may still be benefit to something like this.)

[larrykollar]

Sure. In the following example, trailing spaces are represented by underscore.

## This is only a test [onlytest] ##__

When processed, the HTML looks like:

<h2 id="thisisonlyatestonlytest">This is only a test [onlytest] ##</h2>

If the pounds at the end are omitted, or there's only one trailing space, it works OK.

[fletcher]

What version of MMD are you using? I can't replicate your results

[fletcher]

Never mind.

[fletcher]

Found the whitespace issue and fixed in the latest develop commit.

Thanks!

[fletcher]

The --unique option implements this functionality. It preserves manual labels when specified, and works with {{TOC}}.