attr_list does not work with <pre> blocks

[galaxy4public]

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?

[galaxy4public]

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

    this is a pure <pre> block with no
    code inside
    { #id }

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

[galaxy4public]

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

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

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

[waylan]

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.

[galaxy4public]

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.

[galaxy4public]

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.

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

[waylan]

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.