-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow attributes for list items, table cells and rows #250
Comments
I’d find attributes for list items very useful. However, maybe pipe tables should remain simple and another syntax should be used for more complex tables. I like Markdoc’s syntax. I we use a Djot div block instead of Markdoc tags, we get:
With list item attributes, this syntax becomes very flexible. |
Or just something like a RST list table, which doesn't require anything new in the parser. |
Note that the Markdoc-ish syntax doesn’t require changing the parser – it could be implemented via a filter: It’s a div block around lists that are separated by thematic breaks. |
A two-level list to table can also be implemented as a filter. I wrote such a filter for Pandoc. Most of it is about
Extracting list items and converting them to table rows is rather trivial (at least when using SimpleTable as my filter does). One of these days I'm going to rewrite my filter using re to parse width/alignment attributes allowing a "looser" format. |
It was a tangential point in #249: currently djot doesn't provide a way to add attributes for list items, table cells, and table rows.
The syntax would be straightforward, keeping the usual attribute syntax:
|
of a table cell,|
and/or (to be defined) after the final|
of a table row.Here are a few examples:
For the table elements, the rationale is that this way the cell attributes feel "inside" the cell, while the row attributes are stuck besides the row.
With regards to row attribute placement, rows are in a weird middle-ground between blocks and inline, so there is no consistency argument for attributes before it (like blocks) or after it (like inline spans). I think source presentation is less impacted by attributes after the row, so it's my main proposition, but I don't have an opinion about also allowing them before or not.
The consistency is broken for cells, but I think "inside" is stronger than "before" or "after" in a table. Maybe sticking the attributes on the right-hand side of the cell (i.e. just before the right-hand
|
) would be more consistent with other span elements, but it might be confusing to have attributes on both side of the rightmost|
(or maybe not, since one is really inside and the other is outside).The text was updated successfully, but these errors were encountered: