Skip to content

attr_list does not work with <pre> blocks #965

Closed
#967
Closed
attr_list does not work with <pre> blocks#965
#967
Labels
confirmedConfirmed bug report or approved feature request.docsRelated to the project documentation.extensionRelated to one or more of the included extensions.

Description

@galaxy4public
galaxy4public
opened on May 13, 2020

It seems that it is impossible to add an attribute the the <pre> block. It is a block level element, so according to the source code attr_list will try to get the definition from the last line of the block, but this does not happen, e.g.:

```
code block
{ #something }
```

Will be just rendered as:

code block
{ #something }

Or do I miss something and there is some what re: how one can add an attribute to the <pre> block in Markdown?

Activity

  1. galaxy4public commented on May 13, 2020

    @galaxy4public
    galaxy4public
    on May 13, 2020
    Author

    Well, the above is the syntax that would produce <pre><code>...</code></pre>, but even for

        this is a pure &lt;pre&gt; block with no
    code inside
    { #id }

    adding an attribute at the last line will just happily incorporate it into the pre-formatted text.

  2. galaxy4public commented on May 13, 2020

    @galaxy4public
    galaxy4public
    on May 13, 2020
    Author

    As long as it is inline <code> it works, though:

    ```
something
here
``` { #id }

    Will create <code id="id">somethinghere</code>.

  3. waylan commented on May 13, 2020

    @waylan
    waylan
    on May 13, 2020
    Member

    Fended code blocks have their own slightly different syntax (which is common among most implementations) and therefore are not supported by attr_list. However, that syntax is currently limited to a few specific things. Fortunately, the work in #816 will rectify that soon.

  4. galaxy4public commented on May 14, 2020

    @galaxy4public
    galaxy4public
    on May 14, 2020
    Author

    I appreciate the prompt response, but I have a couple of concerns:

    1. The documentation for the attr_list extension does not mention the code blocks (and the inability to work with them) at all;
    2. It seems that there is a trend in the Python Markdown community to put presentation in front of the semantic content structure, e.g. in the majority cases when you try to "dress up" the existing (and compliant to the Markdown syntax) document people will come up with something like "oh, use that extension with a different syntax and you will get the presentation you want".

    Re: the second item -- I think it is a wrong trend since why would I want to restructure hundreds of existing documents just to present them in a different way? I think the approach should be quite the opposite -- we have structured documents and the processor provides the ways how project that structure to the target format (HTML in our case).

    Sorry for the rant. I do not blame anybody, I am just a bit disappointed that the ecosystem of Python Markdown seems to be heading tactically, but not strategically.

    In any case, thank you once again for your prompt response, I appreciate it.

  5. galaxy4public commented on May 14, 2020

    @galaxy4public
    galaxy4public
    on May 14, 2020
    Author

    One could argue that "dressing up" the compliant structure still requires modifications, to answer that - yes, this is correct indeed, but consider the following:

    1. I have around 500 articles with the following code block format embedded in them:
        Some code information is
    embedded in articles.
    1. Now, on May, 14 I decide to add a nicer formatting to the articles I am going to write from that point on, so I would use something like
        :::css
    Some other code information is
    embedded in articles.

    Semantically the structure is still exactly the same to the rest of the articles, but allows me to present the code block better in HTML (for the new articles, while keeping the old one the same).

    If I start to use fenced blocks instead there will be a breaking change (from the structural point of view) and when in 10 years from now I would want to transform my library of articles to some other format -- well, I will have a zoo of multiple structures which is going to be unmanageable. This is the primary reason for my sadness with the current trend focused on presentation before structure in the community as I observe.

  6. waylan commented on May 14, 2020

    @waylan
    waylan
    on May 14, 2020
    Member

    The documentation for the attr_list extension does not mention the code blocks (and the inability to work with them) at all;

    That is an oversight, which should be fixed. Thanks for bring that to our attention.

  7. Imagewaylan
    added
    confirmedConfirmed bug report or approved feature request.
    docsRelated to the project documentation.
    extensionRelated to one or more of the included extensions.
    on May 14, 2020
  8. Imagewaylan
    added 2 commits that reference this issue on May 14, 2020

    Document limitations if attr_list extension.

    3b3681a

    Document limitations if attr_list extension.

    e6c479c
  9. Imagewaylan
    closed this as completedin #967on May 14, 2020
  10. Imagewaylan
    added a commit that references this issue on May 14, 2020

    Document limitations if attr_list extension.

    c9a093c
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

    confirmedConfirmed bug report or approved feature request.docsRelated to the project documentation.extensionRelated to one or more of the included extensions.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions