-
-
Notifications
You must be signed in to change notification settings - Fork 329
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
Comments
Spec says:
So, the question to ask yourself is: could you get
by appending a block quote marker to the beginning of each line in
And the answer is "no," though perhaps some changes to the spec could clarify this. You can get the first line
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
the block quote marker is |
Edit: Upon reconsideration the specification is ambiguous, I've made assumptions in my implementation not given in the specification |
+++ 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.
|
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 <blockquote>
<pre><code>1. a
</code></pre>
<ol start="2">
<li>b</li>
</ol>
</blockquote> or <blockquote>
<ol>
<li>a</li>
<li>b</li>
</ol>
</blockquote> |
Two examples, they differ only in space after
>
.But first renders as:
and second
I'm not sure, which output is better, but I think it should be same in both cases.
The text was updated successfully, but these errors were encountered: