Consider adding id attribute for Details and Tabbed

[imolavirus]

First, thanks @facelessuser for all your work on this package!

Having an id attribute on details elements has been helpful in my project to allow linking directly to a details element in an open state (when by default it needs to be in a closed state). This is what I've been doing...

Markdown:

??? optional-class "Title" optional-id
    Content

Produces output:

<details class="optional-class" id="optional-id"><summary>Text</summary><p>Content</p></details>

Wanted to see if this is something others would be interested in, and if so I could submit a PR to get feedback on my implementation.

[facelessuser]

If I considered this I would not implement it in this fashion. It would need the attr_list extension and be implemented like this:

??? optional-class "Title" {: #optional-id}
    Content

This would be done this way for consistency with other syntax.

I question whether I would do this though.

1. The syntax is done in such a way to match the Admonitions extension which does not allow such syntax.

2. You could always do something like this:

   <div id="optional-id" markdown="1">
   
   ??? optional-class "Title"
       Content
   
   </div>
   

I'm not saying it is a bad idea, only that I question the approach, and while I don't know how you are leveraging the id, I question if it's useful is great enough to require implementation when you can get something very near to what you need with other workarounds.

@gir-bot add S: needs-decision

[imolavirus]

It definitely could be a fringe use case and I'll look into the other workarounds.

Having the id in the details element allows me to use the id as the URL hash. That links directly to where it is on the page and adds the open attribute.

[facelessuser]

Having the id in the details element allows me to use the id as the URL hash. That links directly to where it is on the page and adds the open attribute.

True, but you could still do this with a check of the details relative to the id div#id > details. I'm assuming you still have to use JS to do this, but adding a simple check if the case above is true is not too bad.

[imolavirus]

I like that solution. I hadn't noticed the md_in_html extension before.

Thanks!

[facelessuser]

I'm considering a new format potentially. One that may not require indentation. Of course, this would allow for IDs to be set on Details, Tabs, etc.

https://github.com/Python-Markdown/markdown/issues/1175#issuecomment-1204715550

Anyways, this is just a thought. I may still retrofit some kind of ID on the old syntax still. I'm not really sure what I'm going to do, but just looking at options.

[facelessuser]

The one thing which was holding us up on this issue is we wanted to match Admonitions in the official Python Markdown library. We wanted consistency, and we wanted to see what they would do. One thing holding them up was exploring this new directive-type syntax.

Well, I sat down and fought the Python Markdown parser to prototype generic, directive blocks which can be used to do Admonitions, Details, and potentially other things like figure captions, etc.

#1777 is an experimental approach to Details, Admonitions, Tabbed, and potentially new and different block-based constructs.

The one thing I really like about this is that it is not indented like the old format which we stole from Admonitions. This won't cause my editor's syntax highlighting to go crazy either.

Additionally, if we want to add new features, we don't have to come up with yet another specialized syntax, we can just use directives.

This is not guaranteed but is currently just an experiment. Even if we do this, we won't be killing off legacy tabs or details any time soon. I realize there are many people using this syntax.

:::{details} My summary
---
type: note
id: my-id
---

Whatever content I want.
:::

If we don't go this route, I could see us maybe just tacking on attr_list under the header of Details and Tabbed:

??? note "Summary"
    {#id .class}

    content

This would help us avoid dealing with the title issue and potentially breaking people. If needed, we could even make this an opt-in approach optional in case adding this new attr_list support under the header surprisingly breaks stuff.

I probably won't be doing both. It's probably the directive approach or patching the old approach. This is because we will likely sunset the old Details and Tabbed approach and move towards the new flexible directive approach.

[facelessuser]

This will be handled in the new general-purpose block extensions. We currently have a beta release 9.10b1 that implements this.

Basically, we rewrote things like Details, Admonitions, and Tabbed to all use this new format. It does away with the requirement to have all the content indented requiring deep indentation for deep nesting. It also has a built-in way to assign arbitrary attributes.

/// details | Summary
    attrs: {id: my-id, class: note my-class}

Content
///

Read more here: https://facelessuser.github.io/pymdown-extensions/extensions/blocks/plugins/details/