Markup: 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]

:+1:

[ikhattab]

+1

[ahmdrefat]

+1

[m-bodmer]

+1

[evilsocket]

:+1:

[dotnetwise]

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

[korczis]

:+1:

[georgw777]

:+1:

[dotnetwise]

Github people are you sleeping?

[michaeldjeffrey]

+1

[georgw777]

+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 [email protected] 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]

:+1:

[adam-lee]

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

[england]

+1, i cannot live without checkboxes in readme!

[aelgru]

+1

[georgw777]

I'll die

Please add checkboxes

[beggerss]

+1 this would be great

[ChrisCummins]

:+1:

[jamesfe]

Read only checkboxes would be nice.

Or at least mention explicitly in the github flavored markdown page (https://help.github.com/articles/github-flavored-markdown) that these are not supported in readme.md files, that would have prevented me from searching for this issue.

Thanks!

[killercup]

I was totally expecting readonly checkboxes as well.

[ajmalafif]

this would be awesome!

[dtudury]

I don't actually understand where I can use checkboxes...
but where I'd like to use it is on my readme's (read only)

[aelgru]

@dtudury you can use them within issues, good example PyBuilder issue #26

[yanek]

+1 on readonly checkboxes too!

[v2e4lisp]

+1

[reinpk]

+1 for read-only on readme's

[felipap]

+1, but they're not gonna do anything about it, are they?

[esbanarango]

+1

[JustinAiken]

+1 :+1: +1

It's okay if they're read only, but they should exist. For example, this Github plugin I'm working on is currently very ugly - if the checkboxes were simply rendered, it would be wonderful.

Of course, actual [x]'ing of the [ ]'s would be done manually as code is commited..

[samcreate]

+1 I read the reasoning for not doing and I thought.... mumbo-jumboooooo.

[White-Tiger]

+1 read-only (it took me minutes to figure out it doesn't work at all^^ damn it..)

[abluescarab]

+1 for read-only! I would love to at least show others what's left to go and what's done.

[Kurios]

+1 Read Only

[mariussoutier]

+1 read-only checkboxes

[muellerj]

+1, read-only is more than fine. Foreign gists are rendered the same way already.

[fbartho]

:+1:
Read-only is perfectly fine. Every markdown renderer chooses exactly what to display for a particular semantic item, rendering these would be fine as well.

[mojavelinux]

Rather than using disabled checkboxes, perhaps the right solution here is to use glyphs via HTML entities. This would allow them to pass through the HTML sanitization filter as it is today.

I recommend the following two glyphs:

• unchecked: hex # 9723, preview: ◻
• checked: hex # 8864, preview: ⊠

Both characters are defined in the standard HTML 5 set, as far as I understand it.

The ballot box glyphs are not in the standard set and don't render on a few systems I tested, so I think the ones above are a better choice. Feel free to correct me if I'm mistaken.

[tomasdev]

:+1:

[xta]

+1

Task lists (read-only) do not render in any local markdown file?

The GitHub md guide says:

Note that some features of GitHub Flavored Markdown are only available in the descriptions and comments of Issues and Pull Requests. These include @mentions as well as references to SHA-1 hashes, Issues, and Pull Requests. Task Lists are also available in Gist comments and in Gist Markdown files.

[drKnoxy]

+1 for read only checkboxes or icons or something

[mcdujan]

+1

[bkeepers]

Hey everyone, we hear you! I'm really interested in this as well. It's not my highest priority at the moment, but I hope to look into it soon. Sit tight!

[aelgru]

Free :icecream: for @bkeepers after implementation!

[bkeepers]

@aelgru you just gave me a good idea for a micro-:icecream:-payment feature on GitHub: a +1 comment is a pledge to the person that fixes it.

[juancampa]

+1

[kaelhuerta]

We all want checkboxes...

[Pacoup]

Yeah, this is pretty stupid. I mean, if the standard is too stupid to include this feature, why not do just that and enforce it to clients. Make a new version of the standard happen. This isn't really helping GitHub as a tool right now.

[thisisyoon]

+1

[jamiis]

:pray:

[montchr]

+1

[gabrielmaldi]

+1

[rhysd]

+1

[dnissley]

+1

[9000-volts]

+1

[KyleChamberlin]

+1

[tobiasvl]

:+1:

[safajirafa]

Emoji? with autocomplete :cool:

:ballot_box_with_check: Todo 1
:ballot_box_with_check: Todo 2
:ballot_box_with_check: Todo 3

[0xazure]

+1 for read-only checkboxes.

[OneHoopyFrood]

+1 for read-only checkboxes.

[jrasm91]

+1 for read-only checkboxes!

[ray-z]

+1 for read-only checkboxes

[alrik11es]

Do not forget to add it over wiki also :+1:

[tgvaughan]

+1 for read-only checkboxen!

[marcioAlmada]

:pray:

[digitaldesigndj]

:+1: Read Only please?

[bkeepers]

TADAAA! :confetti_ball:

You all can give @raganwald a hug (or a firm handshake if you're not the hugging type).

https://github.com/blog/1825-task-lists-in-all-markdown-documents

[OneHoopyFrood]

THANK YOU!!!!

• [x] Amazingness

@raganwald (Hug)

[raganwald]

Shhh, but just between us:

rendered prose diffs work for task lists

https://github.com/raganwald/plain-speaking/commit/7087f790ca84601e9463853c292244927a7c466a?short_path=5b51c9e#diff-5b51c9e8380c18fc2ee8d866662d01d8

[korczis]

:+1:

[aelgru]

+1

2014-04-28 19:23 GMT+02:00 Tomas Korcak [email protected]:

[image: :+1:]

—
Reply to this email directly or view it on GitHubhttps://github.com/github/markup/issues/208#issuecomment-41586970
.

[dtudury]

+1

[JustinAiken]

Thanks :beer:

[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 :beer:

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

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

[raganwald]

Thanks for the spacing :bug: 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! :beers:

[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 :smiley:

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

[codeaholics]

Awesome. Thanks guys!

[rhysd]

Thank you @raganwald!
It's awesome :beer:

[tgvaughan]

Thanks @raganwald, this is brilliant!

[KyleChamberlin]

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

[georgw777]

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]

:+1:

[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