# Blockquotes - whitespace after \`\>\`

**URL:** <https://talk.commonmark.org/t/blockquotes-whitespace-after/2956>\
**Category:** Spec\
**Created:** [October 7, 2018, 3:14pm UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956 "2018-10-07T15:14:07Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Heziode](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/heziode/32/1454_2.png) [@Heziode](https://talk.commonmark.org/u/Heziode)\
**Post date:** [October 7, 2018, 3:14pm UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/1 "2018-10-07T15:14:07Z")

</div>

Hi,

In the spec it is mentioned that a blockquote doesn’t require a whitespace between the blockquote character `>` and the content of the blockquote ([example 193](https://spec.commonmark.org/0.28/#example-193)).

Firstly, it makes a small inconsistency with Heading ATX that require a space ([example 33](https://spec.commonmark.org/0.28/#example-33)).

Secondly, we come across a collision with textual smileys. For example, the smiley `>_<` are not parsed like a smiley but like a blockquote with the current commonMark spec.

So, the question is, this will be harmonized ?

Sincerly,

Heziode

---

<div class="post-metadata">

**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:** [October 7, 2018, 5:33pm UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/2 "2018-10-07T17:33:54Z")

</div>

I’m afraid there’s a lot of existing content out there  
that would be broken if we required a space (though  
aesthetically I’d be glad to do that).

---

<div class="post-metadata">

**Author:** ![Heziode](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/heziode/32/1454_2.png) [@Heziode](https://talk.commonmark.org/u/Heziode)\
**Post date:** [October 7, 2018, 5:41pm UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/3 "2018-10-07T17:41:12Z")

</div>

That’s what I think …  
Maybe in a major update (that include breaking changes).

---

<div class="post-metadata">

**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\
**Post date:** [October 8, 2018, 12:19am UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/4 "2018-10-08T00:19:23Z")

</div>

“Commonmark Strict: how Markdown editors _should_ write text markup”, a proper subset of the more permissive Commonmark 1.0

---

<div class="post-metadata">

**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\
**Post date:** [October 8, 2018, 4:38am UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/5 "2018-10-08T04:38:01Z")

</div>

This would be a good rule to add to a [style guide for CommonMark](https://talk.commonmark.org/t/style-guide-for-commonmark/935). You could potentially run an auto-fixer on existing CommonMark documents to enforce the rule.

---

<div class="post-metadata">

**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\
**Post date:** [February 10, 2020, 8:03am UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/6 "2020-02-10T08:03:21Z")

</div>

We should have changed the behavior together with prefixed, ATX headings, which broke, for instance, a lot of readmes on Github anyway.

I believe a compromise would make – or rather: would have made – most sense: a space or tabulator after the “bird track” is optional only if another line marker (`#`, `*`, `-`, `+`) or fence follows, otherwise whitespace is mandatory.

## Quotations

```markdown
>no blockquote!

> blockquote

> blockquote

> blockquote

> blockquote

> quoted code

   > indented blockquote

>>no blockquote

>> nested blockquote

> >blockquote

> > nested blockquote

```

## Headings

### ATX headings

```markdown
># quoted top-level heading

> # quoted top-level heading

> #hashtag in blockquote

>## quoted second-level heading

> ## quoted second-level heading

># # quoted top-level heading

> # # quoted top-level heading

># #hashtag in quoted top-level heading

> # #hashtag in quoted top-level heading

```

### Setext headings

```markdown
> quoted heading
> ===

> quoted heading
>===

>no heading?
>===

>no heading?
> ===

```

## List items

```markdown
>- quoted list item

>* quoted list item

>+ quoted list item

```

```markdown
> - quoted list item
> - quoted list item
>- quoted list item

>- quoted list item
> - quoted list item

> - quoted list item
> - quoted list item

> - quoted list item
> - quoted nested list item

>- quoted list item
> - quoted nested list item

```

> <https://github.com/commonmark/commonmark-spec/issues/634>
>
> \> \[principle of uniformity\](https://spec.commonmark.org/0.29/#principle-of-unifo…rmity): if a chunk of text has a certain meaning, it will continue to have the same meaning when put into a container block (such as a list item or blockquote).
> 
> The following:
> 
> \`\`\`
> List with sublist:
> 
> \- a
> - b
> 
> Exact same lines put in a blockquote container block:
> 
> \>- a
> \> - b
> \`\`\`
> 
> is rendered by CommonMark 0.29 as
> 
> !\[bq0\](https://user-images.githubusercontent.com/2830093/73654648-43fee280-465a-11ea-99e5-6a4a9e4abc03.png)
> 
> Please compare the above with the example given in the spec just below the definition of the \[principle of uniformity\](https://spec.commonmark.org/0.29/#principle-of-uniformity)
> 
> \[A plurality of markdown implementations, including the original Gruber, correctly follow the principle\](https://johnmacfarlane.net/babelmark2/?normalize=1&text=List+with+sublist%3A%0A%0A-+a%0A++-+b%0A%0AExact+same+lines+put+in+a+blockquote+container+block%3A%0A%0A%3E-+a%0A%3E++-+b) in this regard (I'm counting all the CommonMark implementations as one). 
> 
> 
> Another example of the issue:
> 
> \`\`\`
> indented 5 spaces
> indented 4 spaces
> indented 5 spaces
> 
> The above lines, in a blockquote:
> 
> \> indented 5 spaces
> \> indented 4 spaces
> \> indented 5 spaces
> \`\`\`
> is rendered as:
> 
> !\[bq2\](https://user-images.githubusercontent.com/2830093/73656885-0e102d00-465f-11ea-8b4a-963f3aebc18e.png)
> 
> Though \[in this case, all the implementations except MultiMarkdown get it wrong\](https://johnmacfarlane.net/babelmark2/?normalize=1&text=+++++indented+5+spaces%0A++++indented+4+spaces%0A+++++indented+5+spaces%0A%0AThe+above+lines%2C+in+a+blockquote%3A%0A%0A%3E+++++indented+5+spaces%0A%3E++++indented+4+spaces%0A%3E+++++indented+5+spaces%0A). I would say this latter case is esoteric and unimportant. The first case, the handling of nested lists as demonstrated in the first example, should determine the proper course of action.

## Fences

````markdown
> ~~~
> quoted code
> ~~~

> ```
> quoted code
> ```

>~~~
> quoted code starting with literal space?
>~~~

>```
> quoted code starting with literal space?
>```

>~~~
>quoted code starting with literal greater than sign?
>~~~

>```
>quoted code starting with literal greater than sign?
>```

````

## Thematic breaks

```markdown
>___

>---

>***

```

# Optional blockquote suffix

By the way, I also believe that this should have been complemented by the introduction of an optional suffix `<` with the same whitespace rule in front of it:

```html
> foo <

>> bar <<

> baz<

># heading #<
.
<blockquote>foo</blockquote>
<blockquote><blockquote>bar</blockquote></blockquote>
<blockquote>baz&lt;</blockquote>
<blockquote><h1>heading</h1></blockquote>

```

# Generalization

However, _if_ this rule was extended to other line-prefixed blocks as well, it could lead to surprising results:

```markdown
-> blockquote in list item

+# heading in list item

**** fourth-level nested list item

# # heading nested in heading or second-level heading

```

PS: It had been suggested as an option for ATX headings to require a space only for the (rare) top level:

> [@\#heading Not working](https://talk.commonmark.org/t/heading-not-working/819):
>
> I believe that #heading should render as \<h1\>heading\</h1\>, but it is resulting just as #heading. Users need to put an extra space character (like # heading) to output headings. Is this intentional, or a bug? Am I missing something here??

---

<div class="post-metadata">

**Author:** ![Heziode](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/heziode/32/1454_2.png) [@Heziode](https://talk.commonmark.org/u/Heziode)\
**Post date:** [February 10, 2020, 5:06pm UTC](https://talk.commonmark.org/t/blockquotes-whitespace-after/2956/7 "2020-02-10T17:06:08Z")

</div>

Indeed,

I agree the compromise.