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
{{ message }}
Repository navigation
Feature Request: Set HTML "id" for admonition blocks #1174
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.
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
///
Activity
waylan commentedon Aug 13, 2021
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:
Or maybe we use a second line. Like this:
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_listextension is also enabled. When theattr_listextension is not enabled, we can continue to support multiple classes as we do now (but no longer document it).waylan commentedon Aug 13, 2021
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.
waylan commentedon Nov 7, 2023
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: