# Fenced block but not fenced code block

**URL:** <https://talk.commonmark.org/t/fenced-block-but-not-fenced-code-block/2271>\
**Category:** Extensions\
**Created:** [October 23, 2016, 3:01pm UTC](https://talk.commonmark.org/t/fenced-block-but-not-fenced-code-block/2271 "2016-10-23T15:01:46Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![zzzzBov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zzzzbov/32/218_2.png) [@zzzzBov](https://talk.commonmark.org/u/zzzzBov)\
**Post date:** [October 24, 2016, 2:09am UTC](https://talk.commonmark.org/t/fenced-block-but-not-fenced-code-block/2271/2 "2016-10-24T02:09:19Z")

</div>

> [@Jerry](#):
>
> we often would like to use an inset with a quote

Using `>` will create `<blockquote>` elements that are appropriate for quotes.

As far as other elements, there are a number of other proposed extensions.

* * *

This one covers attributes:

> [@Consistent attribute syntax](https://talk.commonmark.org/t/consistent-attribute-syntax/272):
>
> Eventually, the spec should specify a consistent way to add attributes to at least the following elements: headers, images, code blocks (and maybe even tables, block quotes and inline code and quotes). The most important attributes are certainly id (to enable links to those elements) and class (for styling) which might have shortcuts like #myId and .myClass but other attributes (like [width and height for images](http://talk.commonmark.org/t/support-for-image-dimensions/148)) are useful as well. Stmd currently specifies [info strings](http://jgm.github.io/stmd/spec.html#info-string) for code blocks. I think …

* * *

This one covers a generic block syntax

> [@Block Directives](https://talk.commonmark.org/t/block-directives/802):
>
> A block directive allows for embedding or calling certain operations that does not require extending the core syntax. (Note: There is a debate between ! vs @ as generic directive indicator. I prefer ! as it indicates embedded content or intent.) Block Syntax Block syntax, using repeated sequence as delineators. !!! & the code fence syntax is used to indicate if content should be treated as normal text or code blocks if no extension found. (Could also indicate to extension on the type of fencin…

* * *

This one covers generic plugins

> [@Generic directives/plugins syntax](https://talk.commonmark.org/t/generic-directives-plugins-syntax/444):
>
> This is a proposal for a generic syntax to accommodate custom directives/plugins, which is as simple and markdown-like as possible while still accommodating a lot of use cases. While not enabling all markdown extensions (e.g. tables, custom linebreak behaviour etc. doesn’t really fit the template), it works for a lot of them. There are three different kinds of directives: [Inline](http://spec.commonmark.org/0.17/#blocks-and-inlines), start with one colon (analogous to spans) Leaf block, start with two colons (analogous to empty divs) Containe…

* * *

This one covers `<aside>`

> [@Pipe character (|) for \<aside\>](https://talk.commonmark.org/t/pipe-character-for-aside/2227):
>
> I was writing a blog post in markdown and I wanted to use an \<aside\> element for a note within the post. \<blockquote\> is often (mis)used for such things, which makes sense because writing: \> \*\*Note:\*\* lorem ipsum is quite straightforward and commonly renders into some nicely boxed content. However, since the content is not a quote and the [HTML5 spec](https://www.w3.org/TR/html51/single-page.html#the-blockquote-element) says: Content inside a blockquote other than citations and in-line changes must be quoted from another source this becomes problematic. I thi…

* * *

None are official yet. They’re all at the discussion point, and there are other proposals. I recommend reading through everything that’s been proposed to see if your syntax fits in with one of these previously discussed styles. It also wouldn’t hurt to add your voice to the conversation, especially if you’re an implementer.

> History is made by those who show up

In this case, the spec is really made by those who implement it. That’s why there’s so much credence given to existing implementations (such as testing via [Babelmark](http://johnmacfarlane.net/babelmark2/)).

That’s not to say you should run off and cowboy code your way to an inconsistent implementation, but trialing one of the generic syntaxes would help as a test case for what works and what doesn’t.

---

_[View the full topic](https://talk.commonmark.org/t/fenced-block-but-not-fenced-code-block/2271)._