https://daringfireball.net/projects/markdown/syntax#list If you consider this the "official spec" it's by design.

The lack of official spec is really holding back markdown, I always find it grating when someone mentions that their site renders "Github Flavored Markdown". It should just be markdown. It would be great if Github didnt have this vendor lock in on markdown

"Vendor lock-in" implies that by choosing GitHub flavored markdown apps are somehow beholden to GitHub. Plenty of independent markdown parsers support GFM. Using GitHub flavored markdown is no more "locked in" than using the Airbnb style guide for JS is. It's just a convenient shorthand for "here are the conventions we use".

I'd argue the official spec is now https://commonmark.org/ - it was partially reversed from the actual implementations in use and their behaviours, and is very highly specific compared to the original guide.

Consider the numbering with html

    <ol><li><li><li></ol>

The purpose is to give the indication that it's a numbered list to the rendering engine in each case. If the spec was to use # # # for a numbered list and a * * * for a bulleted list, it would have have the same result.

That 1. 1. 1. and 1. 2. 3. are both rendered the same is a statement to the loosens of the spec, not the incorrectness of 1. 1. 1.

I’d argue that seeing 1. 1. 1. Is actually better than seeing them increasing but being out of order. Less of a hack and while reading them unformatted you just think of it like a HTML OL with list items. Or of the 1 as a keyword meaning ordered list item.

Needlessly numbering lists when bullets would serve the purpose is one of my pet peeves.

Culturally at GitLab we use numbered lists so that it makes it easy to link and reference someone to a spot on the page.

see https://about.gitlab.com/handbook/communication/#writing-sty... number 13:

If you have multiple points in a comment or email, please number them. Numbered lists are easier to reference during a discussion over bulleted lists.

Interesting. With editable docs, things sometimes get added above the points or reordered and then re-numbered which makes the discussion misleading. The reason I prefer bullets is that it encourages people to quote the relevant section when discussing.

Is #28 mixing up sending and receiving?

>28. If an email needs a response, write the answer at the top of it.

Alternatively, it feels like it could read:

> If an email includes a response, place it at the top of it. If an e-mail requires a response, also make that clear at the very top.

The judgement about whether an email needs a response is left to the receiver who would be responding, in their statement. I like that mental model of things. :)

That leaves room for miscommunication, though. If someone expects a response from me, I'd rather they make sure to ask it at the very top so that I don't miss that request with everything else that's going on.

Re-reading the statement, maybe they simply mean replies should be above the original e-mail rather than inline?

I believe that's what they intended to convey, yes.

Love the meta

Funny you should say that, mine is war and cruelty.

The core purpose of Markdown is for the source to look decent and readable, not match the output exactly. You can tell it's a numbered list, so it works.

That's not a hack, it's part of the official syntax.

It doesn't even make sense to see as a kind of hack.