@jgm, is it possible to do something with floating indentation in blockquotes? I doubt that someone vary it within a single block. This flexibility makes parsers more complex than nesessary (need hacks to remap floating indents or fall into “serial” mode).
If spec allows to terminate blockquotes on indent change (before or after “>”), that sould simplify things.
+++ Vitaly Puzrin [Dec 28 14 00:36 ]:
@jgm, is it possible to do something with floating indentation in blockquotes? I doubt that someone vary it within a single block. This flexibility makes parsers more complex than nesessary (need hacks to remap floating indents or fall into “serial” mode).
Perhaps this is true for some parsing strategies. The flexibility doesn’t complicate the parsing strategy used in cmark and commonmark.js much at all.
Changing this would (a) create an unnecessary divergence from the way just about every Markdown implementation currently behaves, and (b) violate an attractive and conceptually simple principle of uniformity, which says that if
foo
bar
is a paragraph, then
> foo
> bar
should be a paragraph inside a blockquote. So I’m not in favor of the change you suggest.
I meaned a bit different indent cases.
1 Allowing to eat first space
>foo
> bar
2 Floating spaces between nested bq
>> foo
> > bar
Case from your example is not a problem at all - blockquote content has fixed shift for all lines. In my example content shift is drifting on each line.
Are there any cases, when such drifting is really needed? IMHO, visually it looks ugly. It seems, that if user starts using one style, he will keep it the same on all bq lines
while at it
> foo
> foo
should render as
foo
foo
and
>> foo
> > foo
Should render as
foofoo
or the parsing strategy for nested blockquote is to just count the number of > intermixed with less than 4 spaces?
I wouldn’t mind to force the blockquote to be >{n} {m < 4} instead of (> {n < 4})+ (read as as many > followed by less than 4 spaces, vs at least a > followed by less than 4 spaces).
Yes, as in your examples. It would be nice to “fixate” visual vertical lines:
In other case - split blockqoutes to several one. Spaces in any place will be allowed, as before, but “use of the same indentation style” will be required within any single blockquote.
I noticed “simplification” tendency in last specs (emphasis, links/labels, html, line breaks between generated tags) and i like it. Suggestion is to consider blockquotes cleanup too. It’s the most strange thing in all spec.
There’s very strong established tradition in how to handle these cases in Markdown processors:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=>foo
>+bar
http://johnmacfarlane.net/babelmark2/?normalize=1&text=>>+foo
>+>+bar
I agree, it looks ugly. And in some sense, it’s not “needed” – an author could always avoid doing things like this. But the tradition of Markdown has always been to be maximally forgiving and allow sloppiness. (That’s one reason writing Markdown parsers is hard.) If you don’t like this, you might prefer reStructuredText.
@lu_zero, no,
> foo
> foo
should not render as a blockquote with a paragraph followed by a code block, because
foo
foo
(the inner contents of your example, with the > stripped off) doesn’t render as a paragraph followed by a code block.
I don’t like !== I will not do. In other case markdown-it would not support latest v0.13 spec 
.
It’s just a discussion, because i don’t have info about all possible use cases. If suggestion does not pass - no problem.
I stand corrected =)