[Markdown] An option to highlight a "Note" and "Warning" using blockquote (Beta)

[dipree]

Alerts are an extension of Markdown used to emphasize critical information. On GitHub, they are displayed with distinctive colors and icons to indicate the importance of the content.

An example of all five types:

> [!NOTE]  
> Highlights information that users should take into account, even when skimming.

> [!TIP]
> Optional information to help a user be more successful.

> [!IMPORTANT]  
> Crucial information necessary for users to succeed.

> [!WARNING]  
> Critical content demanding immediate user attention due to potential risks.

> [!CAUTION]
> Negative potential consequences of an action.

Here is how they are displayed:

Note

Highlights information that users should take into account, even when skimming.

Tip

Optional information to help a user be more successful.

Important

Crucial information necessary for users to succeed.

Warning

Critical content demanding immediate user attention due to potential risks.

Caution

Negative potential consequences of an action.

Update - 14 December 2023

• Changelog: New Markdown extension: Alerts provide distinctive styling for significant content
• Updated documentation

Update - 14 November 2023

• Add support for [!TIP] and [!CAUTION].
• Add support for alerts in Markdown files on GitHub Mobile apps. (pending a mobile app update)
• Add support for various Markdown extensions such as Math rendering, relative links, task lists, animated image player and footnotes.
• Prevent alerts from being nested within other elements.
• The initial syntax using e.g. **Note** isn't supported any longer.

Update - 12 October 2023

• Fix bug where alerts aren't rendered in Markdown file previews
• Add support for Wikis
• Fix various issues with nested blockquotes

Update - 28 July 2023

Thank you all once again for providing a ton of feedback. Few more changes based on that:

• Support for soft line break in Markdown files.
• Visual improvements to stand out better in content and render appropriately with different font-sizes (comments vs. docs)
• Minor bug fixes

Update - 26 July 2023

Thanks for all the comments, we are working on a handful of fixes. One of them is to support soft line breaks in Markdown documents, so it will work the same in comments versus docs.

Update - 21 July 2023

We've made several improvements in response to your feedback:

• The output will now render as a div instead of a blockquote.
• The text color has been changed to primary from the previous muted version.
• We've tightened our parsing rules to prevent conflicts with other Markdown or HTML on the allowed list.
• Consequently, a line break following the title is now required.
• We've introduced a new alert type IMPORTANT.
• A new syntax, [!NOTE], has been added, which will gradually replace the old one. However, the old syntax will continue to work for some time.

Thanks to all for your valuable input on this topic!

Initial - 10 May 2022

To better highlight and separate certain information from the rest in your documentation on GitHub, we now render a special and accessible note or warning blockquote in Markdown documents. We are using the existing syntax for blockquote and bold text.

Note
The first line must be exactly as shown below. The first letter is case sensitive. The second line can contain your content.

This input:

> **Note**
> This is a note

> **Warning**
> This is a warning

Becomes:

Note
This is a note

Warning
This is a warning

Let us know what you think and how this helps you provide better documentation. Please note that this is a beta feature that might be subject to change.

🐳

[Andre601]

How about **Important** for very important information?
Could be useful in combination with Issue forms to get the attention of the user so that they know what to provide.

Edit: Also, to add to this, maybe extend this behaviour to other parts such as headers in block quotes? I like to use headers because of their larger font size, but right now are they not included in this.

[jsoref]

@dipree can you please update the summary to mention that preview and mobile aren't yet implemented so that people don't have to read through 183 comments / 479 replies to discover this?

[MarcoSteinke]

@sinsukehlab

Just use a 2x1 table in wiki pages:

💡 Tip
I am a tip

⚠️ Warning
Do not read this.

[krystian3w]

Important

@RahulVerma989 (https://github.com/orgs/community/discussions/16925#discussioncomment-7024899) Changelog indicates that you can change the tables to quoting with a header at wiki if you do not nest them.

[krystian3w]

Screenshots for @sinsukehlab - works at wiki:

[sinsukehlab]

@krystian3w Yes, it also works at Wiki now.

Update - 12 October 2023

• Fix bug where alerts aren't rendered in Markdown file previews
• Add support for Wikis
• Fix various issues with nested blockquotes

[laymonage]

Thanks for this!

Any way to customize the text? It would be very useful for non-English documents.

[laserlemon]

Why break it if we don't have to? Is there an advantage to the [!!!! Custom warning!!!!] syntax over [!WARNING] Custom warning?

What bothers me about the repeated ! syntax is that it assumes an increasing scale of severity, and I don't think that assumption will necessarily hold. One could argue it already doesn't apply (are tips really more severe than notes?).

So thinking to the future, how would we add a "question" variant (for example)? Sticking with the syntax we already have would make it trivial to add new variants in the future that support custom text:

> [!QUESTION] Consider this…
> How do we invalidate the cache?

[Crissov]

The point is to get rid of English keywords. The syntax does not have to be restricted to exclamation marks – four or five repetitions are a lot already. It is just that the current syntax uses one.

[Swivelgames]

We should take into consideration that there are existing solutions outside of Github that already support the syntax that @laserlemon mentioned:

> [!QUESTION] Consider this…
> How do we invalidate the cache?

Right now, Markdown files with this syntax are broken when viewed in Github.

It would be great to see this custom text feature. Long awaited! 🎉

[ByScripts]

I stumbled upon this discussion while looking for a way to customize the label.

Because I regularly miss a > [!EXAMPLE] alert.

Currently, I'm doing:

Note

Example:

This is an example...

But it's really not great.

So, being able to do > [!NOTE] Example would be a great addition.

[smileyhead]

I'm currently running into this issue in a repo. It would be really nice if the label was customisable.

[eddiejaoude]

This is amazing 🔥 . This is now getting more features similar to AsciiDocs and AsciiDoctor 🎉

[Anlen02]

great

[toastal]

Except that AsciiDoc has had native admonitions since forever (in the standard, not a GitHub-flavored AsciiDoc fork) but GitHub has never supported styling them at all.

[xmo-odoo]

Except that AsciiDoc has had native admonitions since forever (in the standard, not a GitHub-flavored AsciiDoc fork) but GitHub has never supported styling them at all.

Same with reStructuredText, it has extensive support for admonitions both specific and generic (admonition) in the baseline language, but that gets rendered as essentially garbage.

[nk9]

It turns out you can use this new admonitions hack in reStructuredText as well by just using the 4-space block quote syntax. And you can even indent it using the pull-quote directive.

#. List item

   .. code:: bash

      Do something

   .. pull-quote::
      **Warning**
      
      **NB:** Something to be aware of

Still, I don't understand why GitHub still refuses to allow these with the built-in admonition directives in these languages.

[flying-sheep]

Here is the issue for the broken rST rendering: github/markup#1682

[JonDouglas]

Would love to see more callouts too for different use-cases. These 5 below might be good to start with!

https://docs.microsoft.com/en-us/contribute/markdown-reference#alerts-note-tip-important-caution-warning

I'm not sure if this is only for documentation, but I would use it in general issues and other places supporting markdown. I would especially like to see one that is red in terms of "caution". That might be especially useful with enforcing a code of conduct when you've already provided a warning and would be generally helpful with RFCs(request for comments) about any major signs of caution.

[n1ckwhite]

👍🏻

[toastal]

Support any language

@vassudanagunta AsciiDoctor supports locales for the admonition labels

https://github.com/asciidoctor/asciidoctor/tree/main/data/locale

as well as icons

https://docs.asciidoctor.org/asciidoc/latest/blocks/admonitions/#enable-admonition-icons

[vassudanagunta]

@toastal From your link it seems AsciiDoctor only supports icons in the HTML rendering, not in the source plain text.

[toastal]

From your link it seems AsciiDoctor only supports icons in the HTML rendering, not in the source plain text.

I don't know that you’d want icons in your plaintext as it could be ambiguous at times. Also given how many open bugs there are for CLI tools to remove the emoji from the terminal (it really does look out of place), maybe plaintext is the place to keep emojis out. 🤷

But maybe it could work …and has the advantage of being (somewhat) language agnostic. Some symbols like stop signs are more universal.

[toastal]

AsciiDoc รองรับชื่อภาษาไทย แต่ต้อง compile ใน terminal

[BenLorantfy]

Clever backwards compatible syntax 👍

what about changing the colour of the block quote line to blue / yellow?

if you wanted to go further, you could add a background colour as well that’s a lighter shade of the corresponding colour

[007532234]

😑

[toastal]

You say “backwards-compatible syntax”; I say “spec-breaking & semantic-breaking syntax”

[eduardogerentklein]

How about Check for checked information?

[Kirtishukla2004]

use html text with css

[SleazeStiKs]

Tags like Important, Checked, Issue would be very useful. Having a tag for all states of progress

[Puckky66]

ควย

[Puckky66]

ควยปั๊ก

[Hezethegamer]

Check
This is OK

[YusukeHirao]

Why use the blockquote element?
The content is not always that is quoted from another source.

HTML Standard says:

The blockquote element represents a section that is quoted from another source.

[vassudanagunta]

@YusukeHirao:

HTML Standard says:

The blockquote element represents a section that is quoted from another source.

Agreed that the generated HTML should not use <blockquote>. GitHub can easily have it rendered as a <div> with a warning class.

@tom-sherman:

I don't like the idea of overloading the blockquote semantics to mean something more than a quote.

But since we are defining new syntax, we get to define the semantics. We are specifically saying that > **Warning** is the syntax for a semantic Warning admonition. > in all other cases has block quotation semantics.

I looked at the HTML GitHub is rendering it with, and they are not using a div+class as they should:

<blockquote>
<p><span class="color-fg-attention"><svg>...</svg>Warning</span><br>
This is a warning</p>
</blockquote>

This should be fixed. It not only violates HTML semantics, it's going to make it less accessible. I'm not an expert, but there is probably a proper ARIA way to do this.

[tom-sherman]

I find the conversation around markdown grammar interesting and I think when you consider the design of the markdown syntax it backs up my point even more.

We are specifically saying that > **Warning** is the syntax for a semantic Warning admonition. > in all other cases has block quotation semantics.

Firstly this violates the principle of least surprise - it's not totally clear why that renders a warning aside or callout and not a blockquoted "Warning" in bold.

Secondly, how do I now quote someone that has actually said "** Warning"? It would require escaping. Going a step further, how do I quote someone else's warning callout? Overloading the blockquote markdown introduces new decisions that need to be made, this is bad design overall.

And finally, the proposed syntax changes GithHub Flavored Markdown in such a way that it adds more context to the grammar. I believe this to be the root cause of the two symptoms above.

[toastal]

The idea of GitHub-flavored Markdown changing the semantics of a <blockquote> is hilarious and also bad. This would mean your Markdown isn't supported elsewhere: CommonMark, GitLab-flavored Markdown, etc. Locking yourself into just GitHub will bite you in the future. This should not be done. > is for blockquotes and blockquotes quote content.

[Andre601]

Please Star this repo : https://github.com/shu6h4m/MicroSoft_Activator

Please do us a favour and don't shamelessly advertise your stuff nobody really has interest in.

[benjie]

Could use a pipe symbol (|) instead of a greater than (>) for admonitions, blockquote does not seem ideal.

[Murderlon]

Hi, I like the idea but I would like to propose alternative syntax.

GitHub Flavored Markdown is a superset of CommonMark and thus ideally it stays close to that if possible. The generic directives proposal for CM is already used in the ecosystem, take for instance remark-directive or how it's implemented in the very popular Docusaurus and VuePress.

This is how it would look:

:::note
This is a note
:::

:::warning
This is a warning
:::

This would mean:

• GH markdown is more compatible with other solutions.
• You aren't introducing yet another non-standard markdown feature
• It is more future proof. Directives are generic, future features could be added without inventing new syntax every time.

[spenserblack]

GitHub just made a blog post about the >[!NOTE] syntax and added it to their docs, so I guess the current syntax is here to stay 🤷

[meduzen]

I also made a blog post. 👼

[LuudJanssen]

We created a remark plugin to turn GitHub's syntax into the directive syntax: remark-github-admonitions-to-directives

This helped us reuse markdown files in Docusaurus docs.

[H0llyW00dzZ]

This syntax can be quite confusing, especially when writing in an IDE.

[codingluke]

I think it is great to have the Githup callout syntax as proposed in the issue an now already available. And I also think that the two "callout" and "directives" are only in competition for admonition, not for custom directives.

Why not support directives in addition too? 💪

As all static site generators like astro (starlight), docusaurus, vitepress, marp, sli.dev... are supporting directives, this would be a grate drop in feature :) IMHO I like directives more, as there is no > on every new line.

@LuudJanssen great plugin for remark!

[Tess314]

Nice feature! Any way to use without blockquote though?

[pboling]

There is, yes!
The directives proposal!

[Andrew6rant]

More customization is always nice. What if you could specify the Github's Octoicon, color, and text?

For example:

> **alert#9a6700;Warning**
> This is a warning

to render the alert octicon (https://primer.github.io/octicons/alert-16) with a hex color of #9a6700 and a text of "Warning":

Warning
This is a warning

[DerekNonGeneric]

As @pboling pointed out earlier, I would be wary of providing Markdown authors with syntax specifically to accommodate their Octicon symbol name as it may contribute to vendor lock-in. I do, though, wonder whether this feature is only expected to offer users a couple of options (the fundamentals) or whether we should be expecting more choices in the future? If we have one admonition for warnings, we should be given at least one more for the danger zone/error prone/high severity callout content as well.

With the two current choices of note and warning, I doubt additional syntax for specifying particular Octicon symbol names would really be necessary (or even preferable). In the current rendition of this beta feature, the GitHub Web UI may have implemented these callouts using Octicons, but with the limited subset we were given — only a couple of key choices — I think we can probably do better here.

[NB-Dragon]

I don't think it is a good choice.

But opening up a space for users to pick the best color would be better.

Too rich colors can cause visual fatigue for users。

[Tyrrrz]

Seems like...

> **Note**
> Text

...is currently rendered on the same line in readme files, instead of two separate lines like it does here in discussion comments:

How it's rendered here:

Note
Text

How it's rendered in readme:

[wooorm]

Soft breaks are not part of GFM. They work in comments/issues/prs/releases, but not in readmes/gists.
Comments/etc do use GFM, but they also add more, such as these softbreaks.

[borekb]

Well, if GFM says that linebreaks are parsed as soft line breaks but GitHub does something different in issues/PRs, I'd then argue that issues/PRs are not GFM-compliant.

The GFM spec (https://github.github.com/gfm/) is written by GitHub so they have every opportunity to clarify the situation but they don't, so in my eyes their rendering of comments/issues/PRs is just a different dialect of Markdown and not GFM, though it's close.

(BTW I know this discussion is purely academic 😄.)

[wooorm]

CM deals with parsing. GFM inherits that property.
Breaks (and mentions, gemoji, much much more) do not happen when parsing, they are added later by transforming the HTML.
The recent addition of math is similar: it also transforms the HTML (I believe this to be bad and that is should happen in the parser).
I definitely agree there is a lot of room for improvement of explaining this situation.

You could argue that GFM is not compliant to CM, because it adds onto it.
I understand this point, that comments are not GFM compliant, as similar: I instead see comments as GFM compliant, and CM compliant, but adding more things.

[borekb]

I have to admit that I'm not as sure about the technical details or even terms like you are, but in laymen terms, if comments/issues/PRs started rendering two trailing spaces (line··) or a backslash (line\) as a soft line break, I'd say that they violate CommonMark / GFM. In my eyes, this is not an "addition" like the things you mentioned, this is a change in behavior.

But ok, it's the way it is, in the past I've spent quite some time browsing the "Writing on GitHub" section of their docs to find definitive answers but it's often quite fuzzy 🤷‍♂️.

I'm not entirely confident in their implementation either, for example, this new "Note" / "Warning" feature has a lot of strange rendering bugs like #123 not recognized within it, like if they didn't have tests around this or something which is very hard to believe.

[Andre601]

There isn't really a reason why markdown in issues, Pull requests and discussions can't be GFM. It's just a slightly modified one.

And why it behaves so differently in terms of line breaks should be obvious here: Not everyone who files an issue or posts a discussion knows the ins and outs of Markdown, let alone GFM, so not having to deal with that two spaces thing for line-breaks makes it easier for those new people.

We could argue about the semantics, backwards compatibility, etc. of GFM with CommonMark until the heat-death of the universe. In the end does it not matter here. When adding new stuff is GitHub most likely thinking about how it is the easiest and most convenient to use for the end-users, which may not always be programmers or people with vast CommonMark knowledge.

I mean some other features of GFM are barely known such as that when writing a HEX colour inside an inline-code block, it renders a small icon in that colour: #aabbcc

[nathan130200]

Instead, why not use highlight syntax for >I> will provide Important stuff. >W> -> Warning, >N> for note.

Add an letter and an extra > before to create contextual quote.

Normal quote: > this is normal quote!
warning: >W> this is text for warning quote
etc.

[lishid]

Would be cool if this can share the same syntax as Microsoft Docs "alerts" and Obsidian's "callouts".

MS Docs format [1]:
Supports types: NOTE, TIP, IMPORTANT, CAUTION, and WARNING.

> [!NOTE]
> This is a note. 

Obsidian format [2]:
Supported types: note, abstract, summary, tldr, info, todo, tip, hint, important, success, check, done, question, help, faq, warning, caution, attention, failure, fail, missing, danger, error, bug, example, quote, cite. Types are inspired from Material for MkDocs.

> [!Note] Callout can have an _optional_ title
> Callouts can also be nested:
> > [!Hint]- You can also create foldable callouts with `+` or `-`
> > This is hidden until unfolded.

[1]: https://docs.microsoft.com/en-us/contribute/markdown-reference#alerts-note-tip-important-caution-warning
[2]: https://help.obsidian.md/How+to/Use+callouts

[DerekNonGeneric]

I had never heard of Obsidian before seeing it mentioned here. Other than Obsidian Publish, are other services using Obsidian-Flavored Markdown? I would be curious to know how portable the syntax is.

[klaudiagrz]

NOTE, TIP, and CAUTION types would be awesome to have! 😍

[HotCakeX]

Colors, more colores, yes

[okoyemmeso]

I agree to everything

[christopher3810]

I think this design format would make for a more readable and visible readme file.
Hopefully this will become true in the near future.

[ahmadawais]

This is awesome! 🚀

Would be great if we're offered more customization and standard syntax for these though. That'll allow many tools to auto support this.

Note
This is awesome!

Warning
Going to start using it everywhere.

[PROxZIMA]

This syntax might hinder with what user actually wants to write

> **Note**
> This is a note

> **Warning**
> This is a warning

The user will expect this to be rendered as following because **text** is bold syntax.

Note
This is a note

Warning
This is a warning

Also is blockquote necessary here? It's more like overloading its basic functionality.

Others have proposed great alternatives like Microsoft Docs alerts and Obsidian's callouts in #16925 (comment) and remark-directive in #16925 (comment)

Here is my take on the syntax. Suggestions are welcomed.

--[!Note]
This is the subtext for Note
until line break, `<br>` occurs

--[!Warning] 
This is the subtext for Warning
until line break, `<br>` occurs

--[!Alert] 
This is the subtext for Alert
until line break, `<br>` occurs

[pboling]

There is a Markdown RFC for a standard that would support this already. Not sure why they didn't use it, but it would be better to collaborate with the Markdown spec than make GFM even more of a monster.
More: #16925 (comment)

[goyalyashpal]

i was thinking maybe (i) and /!\ can be used in some way too? to make it more strong and unambiguous - syntax wise

[lgrachov]

@dipree Do these work on GitHub Pages and with deploying locally with Jekyll using the github-pages gem?

[pboling]

The answer is "no".

The reason why has a lot to do with a wet fish slap. /s

[nisbet-hubbard]

For a workaround, here’s how GitHub Docs does it: https://github.com/github/docs/blob/main/src/content-render/liquid/spotlight.js

The same thing can be achieved with include tags plus the alerts.scss from the same repo, without using any JavaScript.

[Helveg]

Hi! I've went ahead and created a Jekyll plugin that renders GitHub flavored admonitions! Try it out here: https://github.com/Helveg/jekyll-gfm-admonitions

Building GitHub Pages with custom plugins can be quite involved, but I included detailed step-by-step instructions. It would be incredibly useful if you could let me know of any hiccups you encounter along the way. My plugin works both locally, and in a GHA-driven Jekyll build, with the github-pages gem.

[ReenigneArcher]

Update - 12 October 2023

Fix bug where alerts aren't rendered in Markdown file previews
Add support for Wikis
Fix various issues with nested blockquotes

Nesting isn't working.

1. Something

   > [!WARNING]
   > Doesn't work

Result:

1. Something

   [!WARNING]
   Doesn't work

[nblum-mdmi]

Any idea why they removed this functionality, or how we could request for them to add it back? Not being able to nest callouts is kind of limiting.

[pboling]

You can't fix a dumpster fire unless you put out the flames. The flames are the feature in this case.

[OnkarRuikar]

You can't fix a dumpster fire unless you put out the flames. The flames are the feature in this case.

The feature doesn't work well with Prettier as well: prettier/prettier#16454
Either have to drop Prettier or the feature. 😞

[pboling]

This feature is a poison pill for any project that uses any tools outside GitHub, and even a lot of the tools inside GitHub. It will never be part of the Markdown spec, and implementations in many other projects will be contested and contentious, because of how obviously terrible this particular implementation of annotations is.

[ReenigneArcher]

Doxygen already supports this syntax: https://www.doxygen.nl/manual/markdown.html#mddox_github_alerts

[dynamicsoar]

Hi,

I am wondering why Caution seems more "dangerous" than Warning, while I believe they should (in general) be reversed...?

cf. (among others)

• Caution and Warning should be reversed favoloso/remarkable-admonitions#4 (comment)
• https://www.osha.gov/etools/powered-industrial-trucks/types-fundamentals/parts/

I'm really reluctant to point this out as I guess people should have already considered this, but I could not find any by skimming this long threads so... just in case.

[pboling]

This feature was not well considered or well researched. We need to keep making noise about the many, many problems with this feature, and perhaps other GitHub staff will take notice someday. Don't gaslight yourself into thinking the problem is you. It isn't you.

[dynamicsoar]

Thanks a lot for your kind words. I originally noticed this issue when a cloud-based wiki service I'm using (esa.io) implemented some alerts mimicing the ones in here: https://docs.esa.io/posts/505 . I at first thought I would just tell them there, but I thought perhaps it's better I make a comment here as the impact would be much greater.

[otabekoff]

Hi, can you add option to rename the titles of these blockquotes?

For example if I want to write them in any other language for different language users English words are not perfect fit. For instance of Spanish:
Nota, consejo, advertencia instead of Note, Tip, and Warning? Or is it possible even now? How?

[pboling]

I think they saw this feature as low hanging fruit, which they could implement with CSS tricks, based on reusing the existing parser turning the > into an HTML <blockquote>. From the beginning this was supposed to be a quick win.

If you look at @dipree's profile's README, he changed it about a year ago. It used to highlight the fact that "tiny wins, little changes" were his team's primary focus. This being a "big change, hard thing" is way outside the scope, and unless we make A LOT MORE noise, it is unlikely to ever be noticed.

I've copied what his profile used to say, which is highly relevant to this feature, and also screenshotted it in case it finds a memory hole:

Hi there, I'm @dipree. I'm working for @github on the 🐳 Special Projects team as Product Manager. Our goals are tiny wins, little changes with a relatively high impact. Our routine is to address papercuts, often multiple times a week. In case something is itching you, we are open to feedback, drop me a DM on Twitter or create a discussion in our public feedback repository.

[pboling]

I have to add that it is the pinnacle of irony that he changed it to say that his focus is now on making GitHub a more accessible place for all developers (emphasis mine, and certainly not his), when this feature does exactly the opposite, for non-English speaking developers, and for disabled developers using assistive technologies (as I've documented heavily previously).

[ReenigneArcher]

This whole feature is pretty broken to be honest. In addition to not being able to change the language, you also cannot indent these at all (pretty terrible looking if your admonition applies to a nested bullet point).

If you only care about rendering on GitHub, might be better to just make your own admonition with emojis. https://www.markdownguide.org/hacks/#admonitions If you need it to work outside of GitHub consider using an image instead of an emoji.

GitHub should also probably being using the mkdocs syntax for admonitions instead of re-inventing the wheel. That's the syntax supported by any markdown renderers that currently support admonitions.

[otabekoff]

@ReenigneArcher Yeah, I am barely using those kind of adminitions. Barely, just barely. 😟🥺😢😭

[tomasdev]

Being able to rename the headings would enable the "good code vs bad code" pattern for guideline documentation

[ryanwinter]

I wish this worked while indented :(

Note

This is a working note!

> [!NOTE]
> Not when indented ;(

[pboling]

I am glad it doesn't because this is a terrible implementation, and the better it works the more things it will infect.

This is a poison pill feature. Read up on some of the above threads, but most specifically this one about the nesting:
#16925 (comment)

Do not use this feature!

[sinsukehlab]

Hey, four or more spaces of indentation composes indented code blocks in Markdown (CommonMark).
I am also glad that this authentic Markdown feature hasn't been polluted with the poison pill 'alerts' feature.
Cf. https://spec.commonmark.org/0.31.2/#indented-code-blocks

Examples

Note

This is indented with one space.

Note

This is indented with two spaces.

Note

This is indented with three spaces.

> [!NOTE]
> This is indented with four spaces, meaning a code block!

[pboling]

@ryanwinter @sinsukehlab is saying the same thing I am, but you gave him a thumb up, and me a thumb down? Your contrbution to the discussion will only elevate the discussion if we keep it focused on what needs to change. Supporting indents in the current iteration is not what needs to change. Did you read any of the posts that came before yours? Perhaps you can help us with this disaster of a feature, since you work at Microsoft?

[mkurz]

Please support Obsidian syntax to set custom title, thanks (https://help.obsidian.md/Editing+and+formatting/Callouts#Change+the+title)

[pboling]

It won't happen, unless GitHub pays attention to us (we have no evidence of that). See: https://github.com/orgs/community/discussions/16925#discussioncomment-10458963

[tearfur]

This doesn't work if nested in bullet points.

Example

> [!NOTE]
> Test note

> [!IMPORTANT]
> Test important

- Test bullet
  > [!NOTE]
  > Test note
- Test bullet2
  > [!IMPORTANT]
  > Test important

Note

Test note

Important

Test important

• Test bullet

  [!NOTE]
  Test note

• Test bullet2

  [!IMPORTANT]
  Test important

[pboling]

#16925 (comment)

[jjspace]

This is, unfortunately, intentional

Update - 14 November 2023

• Prevent alerts from being nested within other elements.

It's been discussed multiple times above and is clearly something that should work (and people want) if the feature is thought out and implemented fully

• comment-7618439, comment-7574895, comment-7868288, comment-7936248, comment-7888245, comment-8148855, comment-8383959, comment-8494315, comment-8542131, comment-8590818, comment-8804836, comment-9156825, comment-9538837, comment-10195289, comment-10575676, comment-10620802

[pboling]

Look at GitHub making us do their job for free! Thanks @jjspace for the commitment to "exposing bull shit when you see it".

[MikePendo]

Hi
maybe someone could assist me I would like to have the following:

Important

Requirements:

• XXX
• YYY
  Move Tab to left:
• ZZZ
• QQQ

is it possible to move Move Tab to left to the left i.e indent it with rest of the bullets

[pboling]

This feature is a dumpster fire. It is intentionally broken.

Fom directly above...

This is, unfortunately, intentional

Update - 14 November 2023

• Prevent alerts from being nested within other elements.

It's been discussed multiple times above and is clearly something that should work (and people want) if the feature is thought out and implemented fully

• comment-7618439, comment-7574895, comment-7868288, comment-7936248, comment-7888245, comment-8148855, comment-8383959, comment-8494315, comment-8542131, comment-8590818, comment-8804836, comment-9156825, comment-9538837, comment-10195289, comment-10575676, comment-10620802

[bewuethr]

At least this aspect is a question about lists in blockquotes with a solution independent of admonitions:

> [!IMPORTANT]
> Requirements:
>
> - XXX
> - YYY
> 
> Move Tab to left:
> 
> - ZZZ
> - QQQ

renders as

Important

Requirements:

• XXX
• YYY

Move Tab to left:

• ZZZ
• QQQ

[MikePendo]

@bewuethr Thanks !

[sinsukehlab]

This is totally independent of admonitions or blockquotes.

- XXX
lazy indent
- YYY


- XXX

left
- YYY

• XXX
  lazy indent

• YYY

• XXX

left

• YYY

[EmilyRosina]

[pboling]

This feature is a dumpster fire. It is intentionally broken.

Fom directly above...

This is, unfortunately, intentional

Update - 14 November 2023

• Prevent alerts from being nested within other elements.

It's been discussed multiple times above and is clearly something that should work (and people want) if the feature is thought out and implemented fully

• comment-7618439, comment-7574895, comment-7868288, comment-7936248, comment-7888245, comment-8148855, comment-8383959, comment-8494315, comment-8542131, comment-8590818, comment-8804836, comment-9156825, comment-9538837, comment-10195289, comment-10575676, comment-10620802

[joshcampbell191]

[sinsukehlab]

Nothing is fine. This is a poison pill feature.

[Crissov]

Test cases

Space variations

Tip

no space

Tip

space before open bracket

[ !TIP]
space before exclamation

[! TIP]
space after exclamation

[!TIP ]
space before close bracket

[!TIP Tips and tricks]
space before additional text

[!TIP(Tips and tricks)]
space before additional text inside parentheses

Case variation

Tip

uppercase

Tip

title case

Tip

lowercase

Tip

mixed case

[!tıp]
Turkish lowercase

[!TİP]
Turkish uppercase

Exclamation variation

Tip

single prefix

[!!TIP]
double prefix

[!TIP!]
prefix and suffix

[TIP!]
suffix only

Text variation

Tip

standard keyword

[!TIPS]
plural keyword

[!TÍP]
diacritic mark

[xkeshav]

these are woking fine in github but when we create npm package and on package homepage it does not render as expected.

how can we make shich support both places? here is one example of npm homepage

https://www.npmjs.com/package/@xkeshav/gh-repo-check

[pboling]

Stay away from this feature if you want your Markdown to work everywhere. There is no evidence that GitHub will be putting in effort to make this a community standard, nor does it seem they will continue improving it on their own platform. The list of bugs is long, and the list of external Markdown tools that don't support is always growing.

[500-internal-server-error]

Can the API (https://api.github.com/markdown) to convert Markdown to HTML be updated to include these admonitions? Currently, it ignores them and pretends it's regular text (e.g., <p>[!TIP]</p>).

[pboling]

Stay away from this feature if you want your Markdown to work everywhere. There is no evidence that GitHub will be putting in effort to make this a community standard, nor does it seem they will continue improving it on their own platform. The list of bugs is long, and the list of external Markdown tools that don't support is always growing.

[israpps]

highlights are not working inside details

collapse

[!NOTE]
a note!

Note

a note!

[jjspace]

This is, unfortunately, intentional

Update - 14 November 2023

• Prevent alerts from being nested within other elements.

It's been discussed multiple times above and has frustrated many people. Maybe Github will finally undo this change but I wouldn't get your hopes up. _{(linking for a record, no need to reply in every thread, don't spam)}

• comment-7618439, comment-7574895, comment-7868288, comment-7936248, comment-7888245, comment-8148855, comment-8383959, comment-8494315, comment-8542131, comment-8590818, comment-8804836, comment-9156825, comment-9538837, comment-10195289, comment-10575676, comment-10620802

[gusbemacbe]

It seems that customising the admonition title works only on VSCode:

But it does not work on GitHub:

> [!WARNING] Cuidado
> Never store your personal access token in a public repository.
> 
> Never store permanently the `.git-credentials` with your Git username and personal access token as a password file on the server.
> 
> Never store permanently the Git SSH key on the folder on the server.

Preview here:

[!WARNING] Cuidado
Never store your personal access token in a public repository.

Never store permanently the .git-credentials with your Git username and personal access token as a password file on the server.

Never store permanently the Git SSH key on the folder on the server.

[jsoref]

I'm not sure which extension is rendering that, but if I were you, I'd be inclined to file a bug against it (assuming it's trying to be compatible w/ GitHub, which made it clear that this wasn't the way they intended the feature to work).