This is fixed in the next build (client-side change, server-side change).
Tim Stone's analysis is absolutely correct. The problem (once again) was this Markdown behavior:
If list items are separated by blank lines, Markdown will wrap the items in <p>
tags in the HTML output.
So you have this:
<ul>
- Hello <li>Hello</li>
- world --> <li>world</li>
</ul>
versus this:
<ul>
- Hello <li><p>Hello</p></li>
--> <li><p>world</p></li>
- world </ul>
This is sometimes referred to as "tight lists" versus "loose lists". The problem is that the behavior was unclear as to what should happen if there's more blocklevel stuff inside the list item, like a block quote. What the original Markdown does (and our versions did so far) is
- In a loose list, handle the whole range of Markdown (sub-lists, blockquotes, headers, you name it).
- In a tight list, only handle sub-lists, and then just do line-level things like italics and links.
So, a block quote inside a tight list wouldn't even work.
Except that it did, sort of. Given this:
- Never say
> never
again
we first handle the list. It's a tight list, so don't do any blocklevel things:
<ul>
<li>
Never say
> never
again
</li>
</ul>
But now that we have this, the top-level blockquote handler runs (blockquotes are handled after lists). As most things in original markdown, this is just a string-replacement that updates what we have so far, and it is roughly as smart as Gary Larson's Ginger:

Here's what we say to the blockquote parser and what it hears:
<ul> blah
<li> blah
Never say blah blah
> never > blah
again blah
</li> blah
</ul> blah
And so it creates this:
<ul> blah
<li> blah
Never say blah blah
<blockquote><p>never <blockquote><p>blah
again blah
</li> blah
</ul> blah
</p></blockquote> </p></blockquote>
– which looks reasonable on the right, but is horribly broken on the left. However it's broken in a way that gives a good chance that it's still rendered as expected by the browser, which is why most of the time it seemed to work.
From now on, tight and loose lists will be handled identically, and the question whether text that isn't otherwise handled should be wrapped in <p>
tags or not is the only difference between the two. That fixes this issue and various others where broken HTML was created. It's also consistent with CommonMarks behavior, and thus makes sense for us to adopt.
When running this over a bunch of Meta posts, the only post where this change causes an issue is this one, because the contents of the last bulleted list will now be interpreted as headers. Ironically, this particular problem would be fixed by a CommonMark feature that I'm arguing against.
<p>
too (and then there's an empty<p>
afterward), which happens in all browsers. – Tim Stone Nov 1 '12 at 18:08<p>
tag (Chrome N where N tends to inifinity on Ubuntu), but not the<blockquote>
tag. I wonder what would cause the source code to change from browser to browser. – Dennis Nov 1 '12 at 18:13</blockquote>
is at the very end of the post, while in the output, the<blockquote>
tag gets cut short by the next<li>
. – Dennis Nov 1 '12 at 18:20