Support Admonition Boxes in Markdown Rendering
The current plan is to support GitHub's syntax. I've already seen it implemented in several packages, including markdown-it
and pandoc
.
I do plan on extending it to support an optional title. For example,
> [!NOTE]
> Useful information that users should know, even when skimming content.
is their syntax and is implemented with the word Note
being displayed. I'll add an optional title such that
> [!NOTE] Keep in mind
> Useful information that users should know, even when skimming content.
would get displayed with Keep in mind
rather than Note
. Allows for some level of customization and/or internationalization.
I'm also hoping to extend our multiline block quotes to support this. So you could use
>>> [!NOTE]
A large, multiblock note.
>>>
Problem
Currently it is not possible to call out specific items when writing issue/merge request/epic descriptions/comments which may be an important concept or an admonition to the user for a common pitfall.
Usecase
When writing documentation it is useful to call out specific items which may be an important concept or an admonition to the user for a common pitfall.
Examples
Sphinx allows this functionality via custom theming of admonitions; see this presentation slide 13 for an example.
Another example from StackOverflow.
Proposal
Support Admonition Boxes in Markdown Rendering
Add a feature to the GitLab markdown that treats admonitions like labels. Users can add their own with the attributes name
, header_color
, header_text
, body_color
. They could be used in markdown in the same way as codeblocks, except using >>>NAME instead of ```LANGUAGE.
In the example given as an inline image, the values would be:
field | value |
---|---|
name | Note |
header_color | HEX_DARKER_BLUE |
header_text | EMPTY |
body_color | HEX_LIGHTER_BLUE |
The MarkDown would look like: |
>>>Note
Let's say the writer wanted the box header to be "Awesome Note" instead of "Note", then the header_text field could be filled in and that would change all occurrences in documentation as well as keep the notation required short.