Aidan Woods

Most implementations seems to agree with this (though they don't appear on the page for me, can get some results by going through the network responses): etc...

My concern, I suppose, isn't that it's an unintuitive result, rather that the result given by the reference parser contradicts the spec as far as I can tell? I wonder...

(Btw apparently I can't re-open the issue if you closed it o.0 – behaviour is news to me)

I think if you remove the phrase "minimise nesting" then this case becomes undefined. Since the difference between what I've called the expected result and the reference parser's isn't picking...

cc @iology, we've had a [discussion](https://github.com/jakwings/strictdown/issues/4#issuecomment-307256929) which briefly touched on some potential issues with spaces in Chinese texts when using the CommonMark emphasis, so incase you had any thoughts here.

Nothing stopping an implementation from adopting what you've suggested whilst remaining CommonMark compliant right now. At the moment the spec doesn't mandate any particular treatment of the info string (not...

Taking the definition at face value, we consider some contents to be contained in a block quote ```markdown - - - asdf - sdfg ``` Which is parsed alone as:...

IMO we should aim to preserve consistency in the given indentation so that lines that line up in the original text line up when considered as contents of a block...

> Perhaps it would have be better to rewrite the spec from the reader's (parser's) perspective I'd probably agree with that, but I think it's salvageable without a complete rewrite....

I've worked an initial implementation of that algorithm I gave into the parser I'm working on, so the following is now produced (in yaml-ish notation): ```markdown >1. > asdf >...