attr_list ext strips curly braces from table cells

[mfrigerio17]

Curly braces in the elements of a table get stripped away when the 'extra' extension is loaded

#! /usr/bin/env python3
import markdown
from markdown.extensions.extra import ExtraExtension
from markdown.extensions.tables import TableExtension

text = '''
Try {}

A  |  B
---|---
a{}| b{}

'''

extra = ExtraExtension()
tables= TableExtension()

md = markdown.Markdown(extensions=[tables])
print( md.convert(text) ) # this is fine

print("\n\n")

md = markdown.Markdown(extensions=[tables, extra])
print( md.convert(text) ) # curly braces in the table are stripped

The output (comments added manually):

<p>Try {}</p>
<table>
<thead>
<tr>
<th>A</th>
<th>B</th>
</tr>
</thead>
<tbody>
<tr>
<td>a{}</td>  -- braces are there
<td>b{}</td>
</tr>
</tbody>
</table>



<p>Try {}</p>  -- these braces are preserved
<table>
<thead>
<tr>
<th>A</th>
<th>B</th>
</tr>
</thead>
<tbody>
<tr>
<td>a</td>  -- braces gone
<td>b</td>
</tr>
</tbody>
</table>

Is it an intended behaviour?

[facelessuser]

If I had to guess, it would probably be due to the inclusion of the attr_list extension in extra. As there is now additional syntax to be aware of, escaping the leading { may be the way to go.

Now, should attr_list even handle empty {}? That is a good question that should probably get discussed.

[waylan]

Yes, this is specific to the attr_list extension, which extra includes. What is not clear to me is why this is happening in table cells as it doesn't happen outside of table cells.

That said, things like a{} look like code to me and, if it is code, should be enclosed in code spans, which should eliminate the issue.

A       | B
----- | -----
`a{}` | `b{}`

Alternatively, as the attr_list extension adds the curly brackets as syntax, it also adds support for those characters to be escaped; like this: a\{}.

Regardless, the behavior within a table cell should match the behavior outside of one, which it doesn't. So from that perspective we have a bug of sorts.

[jimporter]

Regardless, the behavior within a table cell should match the behavior outside of one, which it doesn't. So from that perspective we have a bug of sorts.

That depends... this is happening because <td> is considered to be a "block level" element:

markdown/markdown/core.py

Line 85 in 6651746

'progress', 'script', 'style', 'tbody', 'td', 'th', 'thead', 'tr', 'video'

Block level elements are allowed (required?) to have their attr lists put on the same line, so that's why this is happening here. Maybe <td> shouldn't be a block level element though...

[waylan]

Block level elements are allowed (required?) to have their attr lists put on the same line

Not true. Of all supported block-level elements, only header (h1-6) and dt elements can have an attr list on the same line. All other block level elements require the attr list to be on a separate line by itself (specifically the last line).

That said, I see we are special casing td elements specifically.

markdown/markdown/extensions/attr_list.py

Lines 120 to 130 in 6651746

	elif elem.text:
	# no children. Get from text.
	m = RE.search(elem.text)
	if not m and elem.tag == 'td':
	m = re.search(self.BASE_RE, elem.text)
	if m:
	self.assign_attrs(elem, m.group(1))
	elem.text = elem.text[:m.start()]
	if isheader(elem):
	# clean up trailing #s
	elem.text = elem.text.rstrip('#').rstrip()

In fact, lines 123 and 124 were added in #267 specifically to ensure td elements get treated as inline elements by the attr list extension. Presumably that fix was incomplete as it is matching an empty list. It appears that that is the only place BASE_RE is used by itself. Everywhere else, BASE_RE is combined with a wrapper that in less likely to result in false matches. We probably need to modify the td case to not match an empty list.

[jimporter]

Oh, hm. I guess I didn't look closely enough at that code. Oh well. vOv