tabatkins
Setting an id on a markdown list item
I don't see a way to specify an ID for a markdown list, e.g.
1. First
1. Second
or
* This
* That
Without this, when the first list item needs an ID, I have to change the whole list to HTML syntax.
https://kramdown.gettalong.org/syntax.html#block-ials provides a possible syntax:
{: #li-one}
1. First
{: #li-two}
1. Second
https://michelf.ca/projects/php-markdown/extra/#spe-attr provides maybe a second:
1. {#li-one} First
1. {#li-two} Second
Yeah, I'm interested in adding this. I prefer the PHP Markdown Extra syntax; given that I've taken some other things from them, I think that's what I'll go with.
One concrete use case: I’ve run into need for this multiple times when answering “exactly where does the spec say this is the required behavior” questions on Stack Overflow — that is, questions from developers who have, for example, observed some (perhaps-unexpected) behavior with their code in browsers and are looking for confirmation that the behavior they’re observing is in fact something required by the spec (rather than, say, a browser bug).
I’ve run into this relatively frequently with questions about CORS and Fetch behavior defined in algorithms in the Fetch spec — but I’ve also run into need for it with other specs as well.
In those cases, to have a shareable URL to provide in the answer, I’ve thus far resorted to either:
- A. If the step includes a reference to a particular term, then I’ve answered with a link to that reference — for example, https://fetch.spec.whatwg.org/#ref-for-fetch-params-preloaded-response-candidate④
- B. If the step doesn’t include a reference to a particular term, I’ve resorted to referencing is using some language like, “In the scheme fetch algorithm, see step 9, substep 14.
A is suboptimal both because the format of the fragment ID is unwieldy (understandably so, because those generated IDs were never really intended for sharing, but instead just for internal use), and because if a new reference to the same term is added earlier in the spec, then that reference I’ve linked to will get renumbered and end up pointing to a different place in the spec than what I intended.
B is suboptimal both because of the verbosity but also because if any new steps are added to an earlier part of the referenced algorithm, then the step I’m referencing will get renumbered, and end up pointing to a different place in the spec than what I intended.
