Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combination of blockquote and list inconsistency #421

Open
dikmax opened this issue Aug 2, 2016 · 4 comments
Open

Combination of blockquote and list inconsistency #421

dikmax opened this issue Aug 2, 2016 · 4 comments
Milestone

Comments

@dikmax
Copy link
Contributor

dikmax commented Aug 2, 2016

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.

@jgm
Copy link
Member

jgm commented Aug 11, 2016

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.

@aidantwoods
Copy link
Contributor

aidantwoods commented Apr 12, 2017

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

@jgm
Copy link
Member

jgm commented Apr 12, 2017 via email

@aidantwoods
Copy link
Contributor

aidantwoods commented Apr 12, 2017

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants