Please consider rendering indented `- [ ]` as checkboxes

[dandv]

Wise words in this part of the FR template:

Therefore, we strongly recommend you to search the forum with possible keywords.
If your request is very similar to an existing one, like it () and make a meaningful comment, rather than creating a new thread. It also keeps the forum sane!

I’d love to comment if only the forum would STOP CLOSING OLD THREADS automatically!

If you find duplicate threads, feel free to send the moderators a message.

The last time I sent a moderator a message about a thread did not turn out well, so no thanks.

Use case or problem

I personally consider it a bug to not render checkboxes if they’re indented as in the screenshot below (repro steps included within):

But apparently this was deemed to abide by the Markdown spec, so here I am upvoting the closed thread:

Indented checkboxes don't render when not next to other ol or ul items

To reproduce: Obsidian 0.9.20 In a blank note or section of a note that doesn’t have listitems type some leading spaces (e.g. 4) leading spaces followed by - and [ ] ( - [ ], or - [x] observe the obsidian rendering is of the plain text. if the above text is located below a list item it renders properly as a checkbox. If the first checkbox is not indented it (and the checkboxes that follow) do render properly. Here is some sample markdown that renders inconsistently: **Bullets** * L…

Proposed solution

The string - [ ] following the zero or more spaces at the beginning of the line could be rendered as a checkbox regardless of the number of spaces preceding the string.

Current workaround (optional)

Add bullets to force a list.

[OlivierPS]

I’m sorry, I can’t reproduce your problem.

With the default Obsidian theme :

With my personal theme :

I wonder if it were a problem with the CSS theme you’re using or a particular CSS snippet.

My two cents…

Olivier

[Tu2_atmanand]

More related bugs :

Data hides in the Reading Mode for Multi-level Indentation

Steps to reproduce STEP 1 : Create note with the following content: - [ ] Suppose say this is a Main task which will going to have only Sub-Tasks and their Sub-sub Tasks | [due:: 2024-10-19] #Test #SubTasks/bugs #Bug - [ ] This is the first Sub Task, updating - [ ] This is the first sub-sub Task - [ ] This is first sub-sub-sub task - [ ] Adding New three level Indentation subTask - [ ] This is second sub-sub Task Adding a line here, the below tasks has been achieved. This line wa…

Cursor position is misaligned for multi-level indentation

Steps to reproduce STEP 1 : Create note with the following content: - [ ] Suppose say this is a Main task which will going to have only Sub-Tasks and their Sub-sub Tasks | [due:: 2024-10-19] #Test #SubTasks/bugs #Bug - [ ] This is the first Sub Task, updating - [ ] This is the first sub-sub Task - [ ] This is first sub-sub-sub task - [ ] Adding New three level Indentation subTask - [ ] This is second sub-sub Task Adding a line here, the below tasks has been achieved. This line wa…

[Tu2_atmanand]

@OlivierPS, try adding a one level indented task just after :

1. A normal line.
2. An indented normal line.
3. After an empty line.

Here is raw text to test this easily. Simply copy and paste from the below blocks :
1. A normal line :

This is a normal line without any indentation of space at start.
	- [ ] This is an one-level indented task

2. An indented normal line :

	This is an indented normal line.
	- [ ] This is an one-leven indented task.

3. After a empty line:

	- [ ] This is an one-level indented task, right after an empty line.

[dandv]

@OlivierPS

I wonder if it were a problem with the CSS theme you’re using or a particular CSS snippet.

I was testing in the Sandbox vault.

Thanks @Tu2_atmanand for the raw text repro.

[dawni]

Assuming Strict line breaks is disabled, examples 2 and 3 are code blocks per CommonMark, which Obsidian renders accordingly. (With Strict line breaks enabled, they’re uninterrupted paragraphs, which Obsidian also renders accordingly.)

As for example 1, consider this:

a
	- [ ] a1

b
	1. b1

c
	- c1

d
   - [ ] d1 (three spaces)

Obsidian handles checkbox markers (a), which are list markers, the same way it handles other list markers (b and c). That seems correct and consistent, in Reading.

d is a checkbox, as it begins with less than four spaces, and Obsidian renders it accordingly.

The seemingly debatable interpretations are the two editing modes’ auto-numbering of b (whose numbers can’t be changed when Smart lists is enabled) and that Obsidian auto-adds list markers at all for a, b, and c. Strictly, I would think those wouldn’t be treated like lists in any way. (It doesn’t bother me; just pointing it out.)

It seems (to me) that none of Tu2_atmanand’s examples should be checkboxes. The unusual part is that Obsidian applies its Smart lists to them when editing.

… in my opinion.

[WhiteNoise]

This is a much broader issue than checkbox items.

According to commonmark, which we try to follow, neither of the below snippets makes a list item (either with 4 spaces or 1 tab).

Text  

     - Item

Text
    - Item

Same goes for numbered lists, and also by extension, todo lists.

So really, a different FR should be opened, asking to break from markdown spec for this case.

[OlivierPS]

Markdown is not “perfect”, we all agree. And there are different interpretations of some unusual or limit cases, we all know. Hence, we have to accept some “limitations” of such or such implementation. Even CommonMark doesn’t cover everything and not every Markdown implementation complies to it completely. But there is a general agreement that Obsidian is pretty close to being totally CommonMark compliant. Thus, we shouldn’t feel too constraint or limited by the Obsidian way of writing in Markdown.

That said, I’m on the same page as WhiteNoise ; I think it’s OK if Obsidian considers that “what is indented by 4 spaces or by a tab and is not subordinated to a list item” is a code block, as explained here in the official documentation.