Skip to content

Feature Request: Set HTML "id" for admonition blocks #1174

Closed as not planned
Closed as not planned

Description

@iBug

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.

Activity

  1. waylan commented on Aug 13, 2021

    @waylan
    Member

    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).

  2. added
    extensionRelated to one or more of the included extensions.
    featureFeature request.
    needs-decisionA decision needs to be made regarding request.
    on Aug 13, 2021
  3. waylan commented on Aug 13, 2021

    @waylan
    Member

    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.

  4. waylan commented on Nov 7, 2023

    @waylan
    Member

    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
    ///
    
  5. added
    3rd-partyShould be implemented as a third party extension.
    and removed
    needs-decisionA decision needs to be made regarding request.
    on Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3rd-partyShould be implemented as a third party extension.extensionRelated to one or more of the included extensions.featureFeature request.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions