Proposal for syntax for attributes on list items#262
Conversation
|
I like it. Is this repo still maintained? There wasnt any feedback so far on it. |
|
It's a natural idea. I just haven't had bandwidth for this recently. |
List items can now have attributes on the following line at content indent:
```djot
- item 1
{.highlight #id1}
- item 2
{data-value="test"}
```
Renders as:
```html
<li class="highlight" id="id1">item 1</li>
<li data-value="test">item 2</li>
```
Works with:
- Unordered lists
- Ordered lists
- Task lists
Related: jgm/djot#262
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
List items can now have attributes on the following line at content indent:
```djot
- item 1
{.highlight #id1}
- item 2
{data-value="test"}
```
Renders as:
```html
<li class="highlight" id="id1">item 1</li>
<li data-value="test">item 2</li>
```
Works with:
- Unordered lists
- Ordered lists
- Task lists
Related: jgm/djot#262
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
|
The single space making the different of item vs content can be maybe for some a bit misleading. I propose to have this appending the item: Refs demo implementation @ php-collective/djot-php#5 This would also be consistent with sub-elements in general (e.g. DL and DD): |
| To attach attributes to a list item, the curly braces must immediately | ||
| follow the list marker: | ||
|
|
||
| +{.blue} A blue list item. |
There was a problem hiding this comment.
What is the expected interpretation for the marker? How does one apply attributes on a given list marker only?
There was a problem hiding this comment.
I guess directly attaching is also fine from parser rules. And would probably make sense.
But if you look at my implementation (and the linked docs examples), you will see that it improves human readability if in this case those are put into the item as appended new line.
And I think one important goal is the readability for humans in the end, in this case the "list" itself.
There was a problem hiding this comment.
Maybe open a new spec PR with your proposed syntax? Then it's easier to compare and discuss.
There was a problem hiding this comment.
I have plenty of open PRs that got almost no review or even any initial minimal feedback.
I would like to first see the maintainer(s) chiming in giving their 5 cents, before I would open up any spec + reference impl PR.
|
I'm a bit undecided, but leaning towards the original proposal (attributes immediately after the list marker): it just seems a bit more obvious in that case that the attribute is meant to apply to the list item. |
|
Thinking about this more I also are in favor of this solution here, my implemented approach fails on certain elements inside the content then, or at least isn't able to do it in all cases. |
Support the djot proposal jgm/djot#262: attributes in curly braces that immediately follow a list marker (no space before the brace) attach to the <li> element, e.g. +{.blue} A blue list item. (a){.bar} Ordered list item with an attribute. 1.{data-value="test"} Numbered item with a data attribute. Works across every marker type (bullet, ordered numeric, parenthesized, roman, alpha, and task lists). A space before the brace keeps the old meaning, the {...} is item content and acts as a block attribute for the following block inside the item. The previous separate-indented-line form is soft-deprecated but still attaches to the <li> for back-compat; marker attributes seed the item and the separate-line form merges on top. Also teach the opt-in blocksInterruptParagraphs mode to recognize the attributed markers so they interrupt an open paragraph just like the plain markers do.
4 participants
As previously discussed in #185
I'm not sure what the process is for a syntax change, so I'm just starting it by adding a description to
syntax.md.If you do like this syntax, I'm guessing I would
syntax.htmlfromsyntax.mdwith djot.luaRendered docs: