Here’s another take on attributes on block elements. The syntax is consistent with Maruku’s attributes. Although Maruku itself has been deprecated in favour of Kramdown, which has a similar but more elaborate attribute syntax.
Paragraph with attributes.
{.myPar1}
> Paragraph with attributes inside a block quote.
> {.myPar2}
> Blockquote with attributes.
{.myBlockquote1}
- list with
- attributes
{.myList1}
and now:
- a loose list
- with attributes
{.myList2}
another:
- loose list
- with attributes
{.myList3}
and now:
- a loose list where
- the last paragraph has attributes.
Note that the indentation of the attribute block is significant.
{.myPar3}
and finally:
- > a list where each
> item is a blockquote
> {.myPar4}
- > to see that everything is possible
> {.myPar5}
{.myBlockquote2}
{.myList4}
Note that list items themselves cannot have attributes.
I’m not sure that attributes on list items have a real use case, can you think of one that couldn’t be solved equally by adding the attribute to the paragraph that makes up the list item? Meanwhile, there is some potential for an unintended clash when the attribute block is on the same line (if admittedly small, but still).
It’s true that the multiline-attribute-blocks is probably harder to implement and I haven’t really made my mind up about it. (Pandoc does allow multiline while MarkdownExtra and Kramdown don’t.) For adherers to the manual-line-wrap philosophy (like jgm who doesn’t use soft-line wraps in his editor AFAIK) it seems needed, for example if you have a key-value-pair with a long value, or a long header with attributes:
### this is a very very very long header {
.with-a-long-class-name}
Whenever I think that there’s certainly no use case for attributes on THAT element, there comes someone along and has a use case for just that… so I’ve tried to cover all elements possible. Maybe someone want to add CSS to TODO-list and therefore want to add {.todo} to the entire list. Or have two different styles of blockquotes…
I don’t know right answer. It’s very difficult to decide where to stop, and when markup spec fall into programming language spec. I’ve seen similar things in YAML, when people try to use custom tags for coding instead of post processing and keeping yaml content separated.
There still are possibility to use HTML blocks for complex things, and block extentions, discussed in other thread. About TODOs - that seems more simple to implement via additional block type, similar to list (IMHO).
I’d prefer to keep simplicity over flexibility, until we have a lot of examples, that are not rare. Don’t know if it’s correct to compare with YAML, but it’s a real example of over-engineering in accepted standard. If you compare specs 1.0, 1.1, 1.2 & 2.0, you will note, that they remove tons of features, added for “flexibility” reasons before.
PS. Of cause, we’ll implement everything that go into final spec, regardless i like it or not.
But it’s true, I don’t see attributes on all elements becoming part of the “core spec” anytime soon. That’s why I put it in a new section called “Extensions” in the draft:
This section contains extensions to the Core Markdown syntax described above. They don’t need to be implemented to conform to this spec. However, if an implementation includes an extension with the same purpose as one of the extensions described here, this spec strongly recommends to implement the syntax described here.
So if an implementation agrees that it’s useful to have attributes on blockquotes and lists, the spec offers a well-specified way on how to do that with a few test cases.
Some attrs are certaintly useful, like span to insert icons. I think the best we can do is to continue collect different use cases, with reference to real life.
BTW, found unclear case for list attr: attempt to check offset from line start will conflict with lazy paragraph continuation principle (offset does not matter). You’ll need to propagate info from the last child to container. Possible, but dirty.
For paragraphs, block quotes and tight lists, the attribute block must
start on a line that immediately follows the corresponding element.
“element” here could be taken to mean “list element”, or “list item”, which is not the case. Would it be better to use “corresponding block” instead? Also, it might be good to explicitly mention that no attributes can be applied to a list item?
Regarding the content, I am wondering: Would it be worthwile to have a simplified definition of attribute specs in the core spec, so they are properly ignored by implementations that do not implement the extension? e.g. it could define the places where attributes can appear, and just define them as { followed by arbitrary text followed by }, without specifying any structure for the contents. One result of this would be that any } inside the attribute spec needs to be escaped, whereas with the current approach it can be ignored when inside quotes.
After thinking a bit, i still suggest to restrict {} to one line if this markup go to spec. That should be reasonable balance between simplicity and features. If someone really needs tons of attrs, probably he has case that doesn’t fit into markdown well. All existing examples are fine with one-line attrs.
I don’t know, if others agree or not. If i skip final spec discussion - count my voice with this remark please.
Thanks for the feedback. I updated the draft with “corresponding block” instead of “element” and changes to the indentation of attribute blocks for paragraphs, blockquotes and lists.
I like the idea of all implementations at least being aware of the {}. However, I fear that this is also the most difficult part in implementing attributes: detecting when something is an attribute and when just part of the text.
This doesn’t work well with hard-wrapped text. The examples collected fit on a single line when they start in the first column. But when they’re part of running text, they might end up being too long. I guess you could always wrap the entire attributes block to the next line (IIRC any amount of whitespace including a newline is allowed between e.g. the link and the attribute block, right?), but I’d still like:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec
laoreet scelerisque ullamcorper {width=32
height=32 valign=center}. Morbi rhoncus vel est eu sollicitudin.
better than
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec
laoreet scelerisque ullamcorper {width=32 height=32 valign=center}.
Morbi rhoncus vel est eu sollicitudin.
or
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec
laoreet scelerisque ullamcorper
{width=32 height=32 valign=center}. Morbi
rhoncus vel est eu sollicitudin.
(Please forgive me for the bad example ;-p)
Would restricting to one line really help with things? It seems just as
easy or hard as multiline emphasis, or multiline link labels?
Long links without attrs will also not work well with hardwrapping
That make sence only for block attrs. Inline attrs breaks are not significant.
I remember, that spec should be for users, and programming difficulties are not a big deals .
But if you are interested - stmd & pandoc use char scanner everywhere. We use line scanner for blocks and char scanner for paragraphs. That makes one things more simple and another things more difficult .
That’s why if block attr will suddently start “float” from left on multiple lines, in our case additional efforts will be required to catch block end right.
