# What is a block?

**URL:** <https://talk.commonmark.org/t/what-is-a-block/3986>\
**Category:** Spec\
**Created:** [October 2, 2021, 5:28am UTC](https://talk.commonmark.org/t/what-is-a-block/3986 "2021-10-02T05:28:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![boehs](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/boehs/32/2332_2.png) [@boehs](https://talk.commonmark.org/u/boehs)\
**Post date:** [October 2, 2021, 5:28am UTC](https://talk.commonmark.org/t/what-is-a-block/3986/1 "2021-10-02T05:28:31Z")

</div>

The term `block` is referred to often throughout the spec, but there is no strong definition. The closest thing is

> We can think of a document as a sequence of [blocks](https://spec.commonmark.org/0.30/#blocks)—structural elements like paragraphs, block quotations, lists, headings, rules, and code blocks. Some blocks (like block quotes and list items) contain other blocks; others (like headings and paragraphs) contain [inline](https://spec.commonmark.org/0.30/#inline) content—text, links, emphasized text, images, code spans, and so on.

But it leaves lots to be desired. What actually is a block? I interpret it as any enclosed data, be that in `***`, or `#`. Is that interpretation correct?

Perhaps a truncated definition should be added to the def list

---

<div class="post-metadata">

**Author:** ![vas](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vas/32/1267_2.png) [@vas](https://talk.commonmark.org/u/vas)\
**Post date:** [October 3, 2021, 10:22am UTC](https://talk.commonmark.org/t/what-is-a-block/3986/2 "2021-10-03T10:22:09Z")

</div>

> I interpret it as any enclosed data, be that in `***` , or `#` . Is that interpretation correct?

Not quite. Emphasized text is enclosed in `*`s but is an inline element, not a block element. Perhaps you missed that blocks and inlines are mutually exclusive categories.

> ### 🌶 grokking blocks and the block hierarchy
> 
> take a document and draw boxes around each of the block type elements ([the spec’s TOC](https://spec.commonmark.org/current/#TOC) serves as a great reference list). If you have two pen colors, use one color for container blocks and another for leaf blocks.
> 
> Why they are called blocks should be pretty apparent now.

The block hierarchy represents the block-level structure of the document. At this point we only have structure, but no text content, i.e. the string of words you are reading now. This is where inline elements come in.

> ### 🌶 grokking inlines and the inline hierarchy
> 
> take the same document as before, but this time underline each of inline type elements (again, reference the spec TOC).
> 
> First underline the smallest elements, e.g. **this run of strong text** , and then draw a _separate_ underline for the containing run of text, e.g. from the beginning to the end of this paragraph. This will help you see that inlines themselves form a hierarchy.

I think the spec doesn’t try to explicitly explain this, and only alludes to it in the _Blocks and Inlines_ section from which you quote, because this is the standard way most (all?) structured text documents are modeled, including HTML, the DOM, LaTeX, reStructuredText, DocBook and Markdown. The spec is not targeted at Markdown users but Markdown implementers. I think it was fair to assume that anyone serious about implementing Markdown is already familiar with this model.

I hope I helped you understand!