attr_list acts on {%

[domeniko-gentner]

My earlier ticket was caused by this.

Example input:

{% for each in articles %}
<p>{{ each.excerpt }}</p>
{% endfor %}

This is a jinja2 block. If the addon attr_list is on, it outputs this:

<p _=% endfor>{% for each in articles %} <p>{{ each.excerpt }}</p>

The weird part is, that only acts on the closing tag.

[waylan]

I suppose we could tweak the regex to not match {%, but technically, according to the syntax, that is valid. We don't require a space after the opening bracket and I suppose an attr name could be %. Seems to me that we should expect Markdown to munge up template syntax. I think a better approach is to have an extension which informs Markdown of the template syntax so it is ignored (as your other issue explores).

[domeniko-gentner]

I suppose an attr name could be %

I disagree. The docs don't mention this and from my perspective, it is supposed to add css classes, which start with a dot. I certainly didn't expect it.

[waylan]

I just noticed that the forth supported format is not mentioned in the docs, which is what is perhaps confusing you.

1. #someid results in id="someid"
2. .someclass results in class="someclass"
3. key="value" results in key="value"
4. checked results in checked

Notice that a single word is a supported feature. While there is limited use for it in HTML, it is a feature of HTML and supported by the extension. That is why endfor is a single word attribute assigned to your <p> tag. I'm not exactly sure how % results in _=%, but given the unusual input, there should be no reason to expect unusual output.

[waylan]

I'm not exactly sure how % results in _=%,

I took another look at this. Internally, we store single term attributes in a dict as {'term': 'term'}. When serializing the output, if the key and value are equal, then the output is altered accordingly (term if output format is html or term="term if output format is xhtml).

>>> markdown.markdown('*foo*{ checked }', extensions=['attr_list'], output_format='xhtml')
'<p><em checked="checked">foo</em></p>'
>>> markdown.markdown('*foo*{ checked }', extensions=['attr_list'], output_format='html')
'<p><em checked>foo</em></p>'

However, the percent sign (%) is not a valid character in a HTML attribute key. Therefore it is escaped/replaced with the underscore, which happens before the key and value are compared. Therefore, even when the output format is html, we still get _="%" because the key and value are not equal.

>>> markdown.markdown('*foo*{ % }', extensions=['attr_list'], output_format='xhtml')
'<p><em _="%">foo</em></p>'
>>> markdown.markdown('*foo*{ % }', extensions=['attr_list'], output_format='html')
'<p><em _="%">foo</em></p>'

It probably makes sense to do something different when an entire key only consists of invalid characters. But it is not clear what that should be. Any feedback is welcome.

[waylan]

@domeniko-gentner sorry I didn't mention this earlier, but you can backslash escape your Jinja syntax so that it is not recognized by Markdown as an attr list:

>>> t = """
... {% for each in articles %}
... <p>{{ each.excerpt }}</p>
... {% endfor %}
... """
>>> markdown.markdown(t, extensions=['attr_list'])
'<p _="%" endfor="endfor">{% for each in articles %}\n<p>{{ each.excerpt }}</p></p>'
>>> t = """
... {% for each in articles %}
... <p>{{ each.excerpt }}</p>
... \{% endfor %}
... """
>>> markdown.markdown(t, extensions=['attr_list'])
'<p>{% for each in articles %}\n<p>{{ each.excerpt }}</p>\n{% endfor %}</p>'

The document by itself would look like this:

{% for each in articles %}
<p>{{ each.excerpt }}</p>
\{% endfor %}

Of course, that still results in invalid HTML as the entire block is wrapped in p tags. But that would be the case regardless of any use of attr lists.

[waylan]

As we have updated the documentation to include the missing details in #987 and it is possible to use a baskslash escape to avoid the issue here, I am closing this. There still is the question about how to handle a key which consists solely of invalid characters, but as the (updated) docs state, that is the responsibility of the document author to address. In the present case, using the backslash escape avoids the issue altogeather.