Sometimes I nest blockquotes inside of list items:
## Partitions
* basic unit of parallelism
* n partitions : n tasks
* ⬆️ partitions : ⬇️ executor memory footprint
> **note** Spark processes data **in-memory**.
* created for every new task (HDFS read, joins, groupBys, etc.)
This renders as a regular blockquote instead of an admonition:
Is this a deliberate design choice, or potentially a bug? I am personally accustomed to using multi-paragraph list items, and it would be really nice to have access to admonitions in them.
Indenting in markdown is a little weird, because at 4 spaces it’s automatically a code block. So I would try to avoid indenting generally. By spec three spaces of indent are allowed as it seems.
Admonitions or alerts are also basically not supported by any markdown editor as it seems, only github, so I don’t really know what the expected behaviour is here, didn’t test it on github. I could see this being a bug (but only because the markdown parser is a little weird).
I agree that it would be awesome to be able to use indented blockquotes in general.
I worked a little bit on this issue before and it seems very difficult to get the styling right in general but especially to get it right consistently across multiple levels of indentation (i.e., nested lists).
Not sure if it’s just a Code Mirror thing or the way we render things in SB.
This is not strictly true. The following source markdown is rendered as in the screenshots below:
> [!NOTE]
> Admonitions work with no indenation
* test
> [!NOTE]
> but break at two spaces
* test test
> [!NOTE]
> but four spaces of indentation are not always rendered as code blocks.
$ pandoc -f commonmark -o output.html <input-file>
$ cat output.html
<blockquote>
<p>[!NOTE] Admonitions work with no indenation</p>
</blockquote>
<ul>
<li><p>test</p>
<blockquote>
<p>[!NOTE] but break at two spaces</p>
</blockquote>
<ul>
<li><p>test test</p>
<blockquote>
<p>[!NOTE] but four spaces of indentation are not always rendered as
code blocks.</p>
</blockquote></li>
</ul></li>
</ul>
I assume you mean that setting the left-margin on the blockquote to be exactly equal to the left-margin of list items is difficult? (presumably, the width of two spaces in a monospace font.) or is there something else to it?
But as it seems github doesn’t do indented admonitions either.
What would you even expect? Should the actually rendered admonition be indented too? because that would seem very weird to me.
Yep, that’s exactly what I’m proposing. An admonition is just a blockquote with some additional styling—perhaps not the most semantic use of the <blockquote> element, but it’s already an established feature in both GFM and SilverBullet.
Here are the relevant questions, in my opinion:
Are there valid use cases for supporting a blockquote in a list item, structurally speaking? Per the example in my last response, this is already natively supported in CommonMark: the rendered HTML contains multiple block-level elements inside an <li>, including the blockquote. I think that provides a pretty conclusive answer.
How should such blockquotes be styled? This is more subjective, but I would argue that a blockquote nested in a list item should be styled differently than one at the top level of the document structure.
To be clear, I’m not talking about indentation just-because. I am using indentation to create document structure. That is, this:
* foo
> bar
* baz
should not look identical to this:
* foo
> bar
* baz
To illustrate my case:
How SilverBullet currently renders a blockquote/admonition in a list item
Take the shallowest blockquote level for adjacent blockquotes? But that would require some weird code gymnastics. Or be ok with what’s shown above? Or something else?
Open to opinions
(There probably is a reason why obsidian doesn’t do that)
But that’s not how Silverbullet works. Silverbullet uses CodeMirror as a “renderer” (except widgets) meaning some expectable issues. To solve this particular issue, which annoys me very much too, we should look more deeply into CSS selector features, I think. I think it’s doable with CSS but haven’t tried myself yet.
OK, for example this example from MKDocs Material project looks like they solved it. (I haven’t looked how they do the styling or what’s the difference in styled HTML code from Silverbullet yet.) But maybe it helps somehow to find the right direction…
Point taken, TIL. I am still very new to understanding how everything is implemented in SilverBullet. Two questions, then:
Would it still be fair to say that SilverBullet generally aims to adhere to the Commonmark standard? From the manual:
[Markdown] has since been standardized into CommonMark, which is what SilverBullet uses (with Extensions).
If so, when someone asks, “What is a sensible expectation for SilverBullet’s rendering of x markdown?”, is it fair to say “it should structurally resemble the result of rendering the markdown to HTML using Commonmark”?
Silverbullet uses the lezer (The parsing framework for Codemirror 6) markdown parser under the hood. Which intern adheres to the common mark spec, so yeah there isn’t much of a choice by choosing that parser. Silverbullet extends on top of that mostly with already existing extensions, so e.g. gfm, etc. Some of which are definitely willingly or unwillingly implemented rather loosely/adhoc. That’s why admonitions are not part of the parse tree for example, or wikilinks have priority issues, or there are 10 ways to create an admonition that doesn’t work on github, but does on SB. So yes it is based of Commonmark, but definitely isn’t super strict about it.
A very integral part of the Commonmark spec is that, while it does talk about layout, it doesn’t talk about style or “formatting”. You are not going to find the word bold, italic, large, small, etc. in there. That’s really the point of markdown. So saying “adhere to to the CommonMark spec” doesn’t really answer the question, because the Commonmark spec doesn’t talk about it.
I think what you wanted to say is “By spec, the example is considered as one blockquote, so it makes sense to project that into it’s styling, by rendering it as one rectangular block.” If I’m correct?
Yes, bingo. Document structure and styling are two separate concerns, yes, but SilverBullet clearly has defined behavior for rendering a single blockquote, so that’s what it should do for the example you provided.
You’ve asked a couple of times how I expect SilverBullet to render a particular case of markdown, and my answer generalizes to “I would start with the document structure produced by commonmark and go from there.” I think virtually all designers would agree on certain sane defaults; e.g., for a nested blockquote to be completely contained inside its parent blockquote, or for a blockquote in a list item to be indented to the level of the list marker.
