This is a known limitation of the attr_list
extension. Some block level constructs in Markdown do not have any way to represent the block level element in HTML. It is simply inferred. For example, consider both tables and lists. Where in the Markdown source is the <table>
or <ul>
represented? It is not. Only the tables cells (<td>
) or list items (<li>
) are actually represented in the Markdown source.
That being the case, how can the document author specify that the attr
should apply to the element that doesn't exist in the markdown source? I don't think it is possible. I included lists in my explanation above because I think the point is more clear. Consider the following list:
* foo
{#baz}
* bar
{#blah}
Is the id="blah"
supposed to apply to the wrapping <ul>
or the last list item of the list? It could be either. However, to work consistently with the first list item, it has to apply to the list item not the wrapping list. That same reasoning would apply to tables. You would only ever be able to assign attributes to individual cells, not the entire table.
Interestingly, a new release of Python-Markdown this past weekend (2014/02/16) includes a fix to allow attr_list to work properly on table cells. I don't anticipate that you will ever be able to assign attributes to the wrapping table element itself.
Perhaps this is a good time to point to Markdown's syntax rules which state in part:
Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself.
Tables are not plain text prose. Therefore in the opinion of many (myself included1) they don't really belong in markdown. That said, the simplest of tables can be fairly simply represented in plaintext, which is why simple table implementations like the one that ships with Python-Markdown exist. If you want to do anything more complex, then you should be writing HTML or perhaps looking at another markup language that has a philosophy that matches your needs.
That said, opinions differ and some third party extensions have been created to work around the above philosophy. Perhaps one of those will better meet your needs.
1: Full disclosure: I am the primary developer of Python-Markdown. Given the above reasoning I would be more inclined to remove table support altogether than to add additional features. However, in order to continue supporting existing users, the existing features will remain into the foreseeable future with no additions to the table syntax. If you really want more features we offer an API which allows you to develop extensions for whatever you want.