commonmark-spec icon indicating copy to clipboard operation
commonmark-spec copied to clipboard

Combination of blockquote and list inconsistency

Open dikmax opened this issue 9 years ago • 4 comments

Two examples, they differ only in space after >.

  1. (dingus)
>1. > asdf
>   > sdfg
  1. (dingus)
> 1. > asdf
>    > sdfg

But first renders as:

<blockquote>
<ol>
<li>
<blockquote>
<p>asdf</p>
</blockquote>
</li>
</ol>
<blockquote>
<p>sdfg</p>
</blockquote>
</blockquote>

and second

<blockquote>
<ol>
<li>
<blockquote>
<p>asdf
sdfg</p>
</blockquote>
</li>
</ol>
</blockquote>

I'm not sure, which output is better, but I think it should be same in both cases.

dikmax avatar Aug 02 '16 12:08 dikmax

Spec says:

Basic case. If a string of lines Ls constitute a sequence of blocks Bs, then the result of prepending a block quote marker to the beginning of each line in Ls is a block quote containing Bs.

So, the question to ask yourself is: could you get

>1. > asdf
>   > sdfg

by appending a block quote marker to the beginning of each line in

1. > asdf
   > sdfg

And the answer is "no," though perhaps some changes to the spec could clarify this. You can get the first line

>1. > asdf

by adding a block quote marker to the beginning of the line, but you can't get the second line, because a block quote marker is either a > that is NOT followed by a space, or a > + SPACE. Thus, in

>   > sdfg

the block quote marker is > (> + SPACE), and the content inside it is only indented two spaces, not three.

jgm avatar Aug 11 '16 19:08 jgm

~~A parser I'm producing based off the specification produces gives the same result.~~

~~That to say, the current behaviour does honour the specification IMO~~

~~That said, given that understanding this difference requires understanding that the blockquote marker actually includes a space – I think this result is horribly unintuitive.~~

~~Perhaps there could be some discussion on requiring that subsequent blockquote lines opportunistically utilise the same marker (either > or >•) as the most recent previously valid "item", much like lists do.~~

Edit: Upon reconsideration the specification is ambiguous, I've made assumptions in my implementation not given in the specification

aidantwoods avatar Apr 12 '17 17:04 aidantwoods

+++ Aidan Woods [Apr 12 17 10:37 ]:

Perhaps there could be some discussion on requiring that subsequent blockquote lines opportunistically utilise the same marker (either > or

•) as the most recent previously valid "item", much like lists do.

I think this is a good idea to explore. It would allow blockquotes like

>this
>one

to work as before. And I would not anticipate much breakage in existing documents if a change like this were made.

jgm avatar Apr 12 '17 22:04 jgm

Although this method wouldn't be entirely consistent with the approach I gave here I think it should probably work almost identically – seeing as blocks like lists are allowed to casually recede in their indentation so

> 1. a
>2. b

Would be interpreted the same as

> 1. a
> 2. b

and the same as

>1. a
>2. b

The only possible (writer) ambiguity I can see with this opportunistic approach is that is:

>    1. a
>2. b

(minimal marker)

<blockquote>
<pre><code>1. a
</code></pre>
<ol start="2">
<li>b</li>
</ol>
</blockquote>

or (opportunistic)

<blockquote>
<ol>
<li>a</li>
<li>b</li>
</ol>
</blockquote>

aidantwoods avatar Apr 12 '17 22:04 aidantwoods