Task lists do not render in README.md

[codeaholics]

Task list syntax (https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments) does not render in README.md

[mfolnovic]

+1

[automaticalldramatic]

Am facing this one too....

+1

[jaymooney]

👍

[ikhattab]

+1

[ahmdrefat]

+1

[m-bodmer]

+1

[evilsocket]

👍

[dotnetwise]

+100 This is rather a stuppid decision to disable them. It should be applying everywhere, especially on readme.md or wiki

[korczis]

👍

[georg-wolflein]

👍

[dotnetwise]

Github people are you sleeping?

[michaeldjeffrey]

+1

[georg-wolflein]

+1

[sstelfox]

+1

[Kurios]

Also true here.

[korczis]

What we can do to wake up github guys?

Time to start petition http://www.change.org/ ?

[psanders]

1+

[benwurth]

+1

[diegomarquez]

+1

[dotnetwise]

-1 github for not even listening

[vmg]

Hey guys! I'm one of the engineers behind our Markup stack. We're well aware that READMEs don't render task lists. This is intentional, and it's been like this since the beginning.

As you probably saw on the blog post that announced this feature, task lists (together with commit mentions, branch mentions, user mentions, and a large list of other super-useful functionality) are a GitHub Flavored Markdown extension. As such, they are not Standard Markdown, and they are only available for comments posted through our web UI.

Since the very beginning, we've made GFM features only available for user content and comments in the website (and not on actual Markdown documents stored in your repositories), because all these features need the GitHub infrastructure to actually work. A link to another repository, to an issue, to a PR or to a user, a task list... All these features are not available on the Markdown documents in your repositories because they are simply not possible to be rendered locally, and even though the GFM renderer that supports them is free and open-source, we really really care about Open Standards, like Markdown, and forcing down our custom features to the Markdown files in your local machines is something we don't believe in.

The case for having task lists work in READMEs and local files is even more specific and complicated, because of the way they are actually implemented. When you post a comment to GitHub with task lists, we carefully store it in the database in a way that allows us to see where task lists are positioned, and allows us to update the value of each checkbox when you click them on the web UI.

When you commit a README to your repository with a task list on it, we have no control on the way the task list information is actually stored (it's your file, in your repository), and changing one of the checkboxes when you click it implies doing something rather awful: automatically committing a new file with your checkbox change to your repository.

The history of a Git repository matters a lot (it matters a lot to us): it's the way you keep track of changes to your software; it's the story of how your project evolved over time, and it's an indispensable tool for writing and mantaining a successful software project. We believe in branches and discussions, in small commits and descriptive commit messages that let you always know when code changes and why it changed. Automatically creating a commit every time you click a checkbox is the opposite of this.

There's nothing stopping you from having checkboxes in your README, but if you have a task there called [ ] Fix issue with rendering, don't you think it would be a much better idea to manually cross it out in the same commit where you perform the fix?

In summary, we don't think that having task lists on a README that can be updated from the web UI encourages a good usage of Git history, or good workflows, and I hope that you guys acknowledge the philosophical and technical reasons that make this feature unfeasible.

I deeply apologize for not bringing this rationale to you guys before, but please don't think for a moment that we don't pay attention to these kind of requests -- we always care, and we discuss and evaluate these things extensively, but sometimes we just get overflowed with requests, and it becomes hard to respond to all of them like they deserve.

Please bear with us. Much love,
vmg

[dotnetwise]

That's not even true. Please re-read again the title of this issue.

You should simply draw [ ] and [x] as

The biggest impediment is that the brackets are drawn very ugly and
meaningless while some readonly input checkboxes would be a lot nicer and
more intuitive.

Your explains are not correct and we can only see that you are trying to
get away from this basic and simple regex to do for nothing, but writing a
long, boring excuse.

It took us almost half year to pump +1 to this issue and you did nothing
until I have contacted the support which did a great job by bringing you
here in less than half a day!

C'mon @vmg, you can do better than moaning around and implement this
very simple ui regex change, at least!

With regards, dotnetwise

[Proplex]

Hey, hey, a response. Well, it sucks that the feature won't exist, but at least now I don't have to twiddle my thumbs for another two months like it did to even get a response.

[codeaholics]

Hello. I'm the creator of this issue. While I can't speak for anyone else, it was certainly my expectation that this would be "render only", and wouldn't support checking/unchecking via the browser. (Which also addresses your comment about changing the state of a checkbox as part of the appropriate commit.)

As for "forcing GFM" on users, how about allowing us to make a choice on a repository-by-repository basis whether we want GFM or not?

This is certainly the first time it's been stated clearly enough for me to understand that GFM (@mentions, etc.) only work on content entered via web forms and not on committed content, but it certainly does seem to be a very hard thing to do if users want it.

Thanks!

On 23 Sep 2013, at 21:33, NemDiggers notifications@github.com wrote:

Hey, hey, a response. Well, it sucks that the feature won't exist, but at least now I don't have to twiddle my thumbs for another two months like it did to even get a response.

—
Reply to this email directly or view it on GitHub.

[ianstormtaylor]

+1 for readonly checkboxes

[marcioAlmada]

+1 for readonly checkboxes PLEASE :)

PS: Or just open source github so we can add this ourselves LOL

[thykka]

TODO

• read-only checkboxes in README.md
• users want it

c'mon guys.. give us something!

[korczis]

👍

[adam-lee]

+1 for readonly. It cannot be that hard...

[dtudury]

+1

[JustinAiken]

Thanks 🍺

[OneHoopyFrood]

Hmmm, not working in preview mode yet I see...

+1 for rendered view in preview mode!

[korczis]

@raganwald Thank you for this.

If you are in SF i will buy you 🍺

If you will make it working without unnecessary new lines between section with nested lines I will buy you another 🍺

See source of this, pls https://github.com/korczis/microcrawler/blob/master/TODO.md

[raganwald]

Thanks for the spacing 🐛 report, @korczis!

[OneHoopyFrood]

Having a few issues myself, though my use is a bit more extensive than most. It's just my way of organizing all the many things I have to do.

See: https://github.com/colepanike/Formicidae/blob/master/TODO.md

[gabrielmaldi]

Weird... it's not working for me on a (private) repo's README.md.

[bkeepers]

We didn't clear the cache yet, so any existing files will need to be touched for the changes to show up. We'll look at clearing the cache in off-peak hours tonight.

[OneHoopyFrood]

I did edit my file. Just a note. Not sure it it'll help.

[gabrielmaldi]

@bkeepers thanks, but I don't think it's an issue with the cache. I created this repo a minute ago and it's not working. Am I missing something?

[bkeepers]

You're right, I see we're missing the flag to enable this on the repo overview page. Fix coming.

[muellerj]

Thanks a lot guys! 🍻

[bkeepers]

Alright. Fixed in READMEs on the main repo view. Sorry for the trouble.

[gabrielmaldi]

Thanks! I can confirm that it is effectively working on the repo overview page 😃

However, it isn't working on forked repos yet. (Sorry for being so annoying 🙏)

[codeaholics]

Awesome. Thanks guys!

[rhysd]

Thank you @raganwald!
It's awesome 🍺

[tgvaughan]

Thanks @raganwald, this is brilliant!

[KyleChamberlin]

Sweet! @raganwald & @bkeepers thanks! glad to see the wikis got the same treatment.

[georg-wolflein]

Thanks a bunch! @raganwald & @bkeepers

[nghuuphuoc]

@gabrielmaldi
However, it isn't working on forked repos yet.

It's working on forked repos.
Now, my BootstrapValidator looks so great! Thanks @raganwald and @bkeepers a bunch!!!

[faizaankhan]

👍

[eugenedakin]

I found out how to do this... This method works - but - your must have a space after the dash:

• first
• second
• third

If there is no space, then it doesn't format:

-first
-second
-third