I agree with most of what you write but I don’t really understand this bit.
First, it actually isn’t sure you want a list but maybe just one instance, just like with e.g a single bullet. IMO it should also work then. Second, that would require resolving the conflict with the regular * bullet. And third, what is not clear with the following?
[ ] milk
[ ] bread
[X] eggs
[ ] apples
[X] cheese
I agree with everything else, even if that magic bit to modify the checklist source from viewmode would be nice.
I think that’s probably for me just a matter of familiarity. The places where I’ve seen this mark it up as a list item. One example, GitHub Flavored Markdown Spec, which uses - rather than * for a list item, but is otherwise exactly what I presented.
I don’t think this is important.
But perhaps a parser could be smart enough to turn * [X] into a checkbox in a list item inside an unordered list and turn [X] into a checkbox in a paragraph.
Yes, but I would like a way to turn it off in any sort of read-only mode.
But IMO the beauty is in the “magic”, that elements can be checked in view-mode, without all the “Edit UI”.
The “Advanced Edit UI” could be an option on a “per item” basis. So
Enable “New list item” input
1.1 Enable “Delete” button.
Enable “Clear all” button
Enable “Sort alphabetically”
The code already exists. Only some more configuration options would need to be implemented.
There is a pending PR at the original repository, which would change the “Delete” button into a “Comment Action”. So deleting would result in <!-- [ ] Bananas -->. So the bananas checkbox would not show up, but would still be in the text. (I think that’s an interesting idea, because removing the comment markup is much less work, than writing a lot of text again. … )
* [ ] milk
** [ ] bread
Creating indented lists is also interesting. Not sure how much more complex the code would get.
This TWClassic plugin was originally written way back in December, 2005 (!!!). Initially, it used “inline X” handling that modified the tiddler’s source text to change between [_] (unchecked) and [x] (checked).
It was then extended to support using other methods of tracking the checkbox state:
[x=id] uses the TWClassic internal ‘config.options[…]’ javascript array. Note that if the id begins with “chk” then the TWClassicCore would automatically track the option setting via a cookie.
[x(title|tag)] uses tiddler tags, where omitting the “title|” syntax ([x(tag)]) sets the tag on the current tiddler and omitting the “tag” syntax ([x(title|)]), uses “checked” as the tag value. Omitting both ([x()]) sets the “checked” tag on the current tiddler.
[_(tiddler@field)] to use tiddler fields. Similar to the tagging syntax, omitting the “tiddler” title ([x(field@)]) sets a field with a value of true or false in the current tiddler and omitting the field name ([x(@tiddler)]) uses “checked” as the field name. Omitting both ([x(@)]) sets the “checked” field on the current tiddler.
I have a hard time letting go of my years of Markdown work, where a top-goal was source-level readability. To my eyes, either of these two syntaxes more clearly describes a checklist than the above:
* [X] milk
* [ ] bread
or
[X] milk
[ ] bread
This is not nearly as important in TW, where source and rendering are just a click apart. But knowing that intellectually is not the same as feeling it. I still absolutely prefer those versions.
By “item”, do you mean one contiguous block of checklist items?
That sounds like a wonderful idea, but I’m struggling with determining a UI that lets you know its there to be restored.
Another idea would be a editor toolbar button that cycles between three states: my text, * [ ] my text, and * [X] my text. Do we have editor toolbars that cycle between more than two states?
If I wrote that, it was by accident! But it definitely is an interesting concept. The trouble is then I’d want to consider more complex behavior, where checking/unchecking a parent check/unchecks all its children, and there might be an intermediate half-checked state for those items that have a mixture of checked and unchecked children. I’ve written that before, and it was reasonably complex, although doable. But I really don’t think we want to go down that road.
… and therefore probably not worth it. This is nice to have. It’s not critical.
That’s fascinating stuff! For our purposes now, we have the $checkbox widget for anything more complex than display and toggle. I would hope this could remain simple.
While definitely interesting, I think this is a step away from some the “readability over formatting” principle for markdown. Also, I think these “shortforms” should have as highest priorities: “effortless to remember and to type”. IMO, [] and [x] are so far the clearest suggestions. (Maybe [] and [ ] could be synonyms - the former is of course smoother to type quickly (imagine a 20 items list!) and the latter has smilar width as when checked.)
If that is to be done, then maybe a similar tactic to what we use for tables could be used, i.e various “flags” to signify e.g h(eader) and f(ooter).
…but for a checkbox list it wouldn’t concern “rows” but instead, as you indicate, more be a matter of adding “surrounding functionality” (- “clear all”, “sort”, etc). So it could maybe be invoked with keywords, something like:
I think I would too. Having check/uncheck items in view mode, but add/remove items in edit mode, feels like the right demarkation to me (though if I got into using checklists heavily, I may change my mind)
I think that would be a good idea. But regardless of that, I would simply like a way to turn it off. I can manage it for myself when I’m toggling my own read-only mode.
I made something based on my other ViewTemplate checklist that is more functionally similar to the markup usage in TW5-Checklist, but they’re draggable. It doesn’t use the $checkbox widget so no field/tag/external tiddler needs to be created, they’re $button-widgets that look like checkboxes that rewrite the text field directly.
It’s also fairly expandable/customizable in terms of applying a template to an individual line with some sort of markup prefix so you can add functionality besides checkboxes.
I’ve dragged the six listed tids, as well as ReadMe: VT-markup as example of a working checklist, to an empty.html to test, and it’s not working. I’ve checked that the content and tags are definitely there, saved and loaded from scratch. Still no dice.
ah perfect. VT-markup before the built-ins instead of after and it’s working a charm!
I’d be curious what the performance difference is between this and the tgrosinger/TW5-checklist solution is. Both are very close to what I’ve concluded I want (human-readable wikitext), with the draggable items and more minimal UI of VT-markup winning me over. Plus for my clumsy/naive awareness of what’s happening under the hood, it seems more extensible too (something I simultaneously appreciate, and probably wont use!)
I too wonder about the performant-ness of my solution… The drag and drop basically duplicates the entire tiddler into a data tiddler before writing it back over the original so depending on the length of the content it could be a lot. It also has issues with how it splits up every single newline and will screw up widgets spanning multiple lines
I have extended the extensibility even more, it now covers some of the other topics that have come up in recent discussions, @JuanPalomo you may be interested in checking it out. I have split up the code a bit so it should be easier to customize for your own needs, and now you can add/remove additional checklist stages that you can write template tiddlers for. You can also now indent for subtasks.
Due to a zero padding issue the drag and drop can handle up to 99 lines whether they be checklist items or lines of plain text, though it would be an easy fix to change the zero padding to allow for up to 999 lines. It is also of note that a list with 99 lines (not all checklist/drag and drop items) does lag like half a second on Firefox though it seems snappier on Chrome, see this example to assess the lag yourself:
(seeing the 99 line long list made me add columns as a feature, simply type the number of columns into a field called “VT-markup-columns” and that tiddler will render with columns)
