# Proposal to relax fenced blocks definition **URL:** \ **Category:** Extensions\ **Created:** [February 11, 2022, 12:48am UTC](https://talk.commonmark.org/t/proposal-to-relax-fenced-blocks-definition/4088 "2022-02-11T00:48:44Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [February 11, 2022, 2:04am UTC](https://talk.commonmark.org/t/proposal-to-relax-fenced-blocks-definition/4088/2 "2022-02-11T02:04:36Z")
The spec calls them “code blocks,” but never says they’re “for code only.” All it says is that “the content is treated as literal text, not parsed as inlines.” This is incompatible with one of your examples (“wrapper with some attributes for inner markdown”). And I wouldn’t want to change that: it would create too much confusion if sometimes the contents were parsed as markdown, and sometimes not. But it is compatible with many uses other than code. Remember, the spec doesn’t prescribe how these elements are to be rendered, just how they’re to be parsed. So, rendering a code block with a certain class as, for example, a diagram, is compatible with the spec. I think that if you want a fenced construct whose contents are parsed as commonmark, a different syntax should be used. Pandoc uses `:::` for this. --- _[View the full topic](https://talk.commonmark.org/t/proposal-to-relax-fenced-blocks-definition/4088)._