I would prefer that HN continues to NOT support Markdown. After all, the entire point of Markdown is that it should be readable in its unprocessed form [1]. Therefore, Markdown obviates its own utility: Why not just present the source text of a comment as-is? Why confuse non-savvy users with behaviour like collapsing line breaks [2]?
[1] "The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions." https://web.archive.org/web/20040402182332/https://daringfir...
- One - Two
HN could be said to have a very minimal Markdown, with it's support for using asterisks for adding italics. We can't have plain asterisks, because of that, though.
I rather have no Markdown than Markdown that doesn't have escaping facilities to allow expressing all plaintext.
- One
- Two
And quotesWith regards to lists, as I can create them, that's all that matters, again the formatting doesn't need to be special, it just needs to exist.
They aren't markdown quotes, which was the claim made. “People on the site use HN’s almost-markdown code blocks for quotes” is true. HN supports markdown code blocks and markdown quotes is not; it supports code blocks in a way that approximates markdowns, and has no separate quote functionality.
> With regards to lists, as I can create them, that's all that matters, again the formatting doesn't need to be special, it just needs to exist.
But...it doesn't. HN allowing you to type text and not transforming it at all isn't support for markdown (or any other kind of) lists. The claim upthread was that lists were another markdown feature that HN supported. It does not. Now, it's true that markdown’s markup for lists is itself a manner commonly used for presenting lists in unformatted text (a very big part of the idea of markdown is that it follows convention for plain-text presentation so that it is readable and recognizable without processing), but not recognizing or transforming a markdown feature isn't support for that markdown feature, even if by the nature of markdown the absence of transformation still leaves the intent recognizable.