For simple projects and tasks, creating subtasks can be necessary. We often use task list in a main task's description to indicate smaller todo items.
Github provided a task lists syntax for that:
https://help.github.com/articles/github-flavored-markdown#task-lists
I think it will be useful.
# [ ] Steal Underpants. # [ ] ? # [ ] Profit
| rPHU libphutil | |||
| D8931 | rPHUd7732a7cc050 Allow Remarkup lists to have checkboxes | ||
| rP Phabricator | |||
| D8932 | rP1876bef40463 Add CSS and docs for remarkup checkbox list styles | ||
This requires writing back into the markup source when it is edited, which we currently don't do anywhere else and which I don't think allows us to build that much other stuff. It's also pretty complicated.
FYI
In GitHub, the generated HTML disabled the checkbox - it is not an interactive piece. It is a pure presentational piece.
To check the checkbox, the markdown source needs to be edited manually.
Correction:
@epriestley was right, the checkboxes are functional UI pieces [1]. I saw it disabled was because of permissions.
[1]: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments
One thing I didn't try was using the element in a README.md -- I can't imagine how that works. My guesses are "it doesn't", "it isn't editable", or "it glitches horribly when the list is edited".
I do think the feature is pretty cool, it's just a lot of work compared to most markup features.
I guess a fourth possibility is: it makes a commit every time you check a checkbox.
I hope it's that.
Mystery solved: it is not supported in (README.md)[1].
Only supported in the GitHub functions, not the rendered repo content.
The blog post says "GFM: Issues/Pulls, Comments" so I think that's where it is available.
An alternate approach would be to implement these lists as first-class objects, so you'd have a button on the remarkup area which opened up an editor or something and then ultimately embedded {X123} (roughly, like files/images work). This would mean you couldn't create these lists from the CLI (like in arc diff) and couldn't edit them when editing remarkup (although the rendered version could let you launch the editor), but would solve all the other issues and maybe open up other integrations.
This would be less complex, but a whole lot of work.
Another compromise we could implement easily is to make these read-only, and you check them off by editing the comment or object description. That would be a little less convenient (to check a box, you have to edit -> place an "X" -> save), but very straightforward to implement and not open up any of the messy questions that a writable implementation implies. Basically, it would just be a new list style, where [ ] renders a (non-interactive) unticked checkbox, and [x] renders a (non-interactive) ticked checkbox.
@qgil, how valuable is the read-only version compared to the read-write version? Rough breakdown here is that read-only will take about 10 minutes, read-write will take 70,000 centuries.
Let me think.
(silence)
I believe we'll go for read-only, then. ;)
Our product guys will be able to edit the markup, sure.
I've marked D8931 (which implements the read-only version) as resolving this task. We might implement the read-write version some day, but the infrastructure complexity and product questions (how do we show edit history?) are hard to justify given that the feature is probably not hugely earth-shattering.
If we develop other features in the future which would benefit from writable, rendered remarkup, that would help support the case for a read-write version of this, but I don't think we currently have any plans or feature requests in this vein.