You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If no self-defined ids are used, there is a chance for duplicate ids. See the following example:
# Head1
Sample text of head 1.
## Head1-1
Sample text of head 1-1.
# Head2
Sample text of head 2.
## 見出し2-1
Sample text of head2-1.
## Head1
Duplicate subheading.
# Head3 {#self-defined-head3}
Sample text of head 3
You'll notice the #Head1 is defined twice and thus will always scroll to the first id, as ids have to be unique.
I thought of two solutions:
Make sure duplicate ids can never happen. If it already exists append something (count?) so it'll stay unique. The downside would however be that the ids will change over time i.e. you bookmarked #Head1_0 it could become #Head1_1 over time.
Use the parent in the id i.e. #Head2_Head1 this at least prevents our described use case, but it'll still allow for the following which would cause the same problem:
# Head
Paragraph
## Subhead
Paragraph
# Head
Paragraph
## Subhead
Paragraph
So the best solution actually might be combination of both. Of course other solutions are welcome.
The text was updated successfully, but these errors were encountered:
A practical solution would be to provide "options" such as "append_numbering" and/or "append_level".
TS; DR
Yea, you got the point. If the header is the same, the bookmark link will be the same. It's been a problem since issue #3. So I think it's a kinda dup-issue, though.
So, the current "best" solution was to "write a document with a unique heading title" ... 😭
But, as you suggested, adding something to the bookmark anchor might be the solution.
Yes, the order may change as the document is updated. Though, this also applies to the header title itself. As long as the link is generated dynamically, there is no way to specify the link permanently.
Thus, a practical solution would be to provide options such as "append_numbering" and/or "append_level" and let the user decide.
If no self-defined ids are used, there is a chance for duplicate ids. See the following example:
Which will translate to:
You'll notice the
#Head1
is defined twice and thus will always scroll to the first id, as ids have to be unique.I thought of two solutions:
#Head1_0
it could become#Head1_1
over time.#Head2_Head1
this at least prevents our described use case, but it'll still allow for the following which would cause the same problem:So the best solution actually might be combination of both. Of course other solutions are welcome.
The text was updated successfully, but these errors were encountered: