Android-FileBrowser-FilePicker
Android-FileBrowser-FilePicker copied to clipboard
Feature Request: Set HTML "id" for admonition blocks
As far as I understand, admonition blocks support extra classes via the syntax !!! class1 class2 class3. It would be nice if this could be extended to support an id for navigation.
Example input:
!!! class1 class2 #my_admonition
Example output:
<div class="admonition class1 class2" id="my_admonition">
It would be better if the hash tag can appear in the class list, so !!! class1 #my_admonition class2 should produce the same output. The behavior would be undefined if multiple "hash tags" are present for the same admonition block, as it's up to the user to ensure the syntax is valid (it's invalid HTML that one element has multiple IDs).
I've seen #685 and it seems at first glance it wouldn't be too complex to add this support, but I'm open to any thoughts and ideas you may have.
Interesting proposal. I'm wondering if perhaps a better solution is to add support for attr_list, much like we do with fenced code blocks. The simple (one class) form can continue to work as it does now, but for more complex situations, the user should provide a curly bracket wrapped attr_list. The tricky part about that is that attr_lists always go at the end, but in admonitions, the title is at the end. How about this:
!!! type "Title" { #id class1 class2 }
Or maybe we use a second line. Like this:
!!! type "Title"
{ #id class1 class2 }
The problem is that that is not compatible with #685. In retrospect, we probably should have implemented this instead. But it's too late to change that now. I would propose that the attr_list should only be supported when the attr_list extension is also enabled. When the attr_list extension is not enabled, we can continue to support multiple classes as we do now (but no longer document it).
BTW, I've been kicking around the idea of creating a new extension for a general purpose block, which could complexly negate the need for the admonition extension. I'm thinking that if this new extension was to be built, then our efforts would be better spent there than on improving the admonitions extension. A rough sketch is outlined in #1175.
I'm closing this in favor of admonition blocks, which is the result of my proposal in #1175. As one of the examples in the documentation demonstrates, any HTML attributes can be defined on the admonition:
/// note | Some title
attrs: {class: class-name: id: id-name}
Some content
///