What is a block?

Spec
1

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—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 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

2

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.

:hot_pepper: grokking blocks and the block hierarchy

take a document and draw boxes around each of the block type elements (the spec’s 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.

:hot_pepper: 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!