Skip to content

attr_list ext strips curly braces from table cells #898

Closed

Description

@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?

Activity

  1. facelessuser commented on Jan 28, 2020

    @facelessuser
    Collaborator

    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.

  2. waylan commented on Jan 28, 2020

    @waylan
    Member

    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.

  3. added
    bugBug report.
    extensionRelated to one or more of the included extensions.
    on Jan 28, 2020
  4. changed the title [-]extension 'extra' strips curly braces in tables[/-] [+]attr_list ext strips curly braces from table cells[/+] on Jan 28, 2020
  5. jimporter commented on Jan 31, 2020

    @jimporter
    Contributor

    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:

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

  6. waylan commented on Jan 31, 2020

    @waylan
    Member

    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.

    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.

  7. jimporter commented on Jan 31, 2020

    @jimporter
    Contributor

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

  8. added 2 commits that reference this issue on Jun 25, 2020
    3d1a571
    c07756d
  9. added a commit that references this issue on Jun 30, 2020
    706d1fd
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

    bugBug report.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