Sub-tasks in tasks lists are not correctly identified by Obsidian

[ChezFrancois]

Testing some custom CSS snippets to make my edition experience better, I discovered a bug in the way sub-tasks are managed by Obsidian editor.

Steps to reproduce

Create a list of tasks:

• [ ] task 1
• [ ] task 2
• [ ] task 3
  Then, insert a Tab before task 2 for example
• [ ] task 1
  →-[ ] task 2
• [ ] task 3

Expected result

Task 2 has a CSS type of a sub-task, that my CSS snippet would transform into a nice checkbox.

Actual result

Task 2 get this CSS type:

<span class="cm-formatting cm-formatting-link cm-link cm-list-1 cm-hmd-barelink">[</span>

It is not a task any more!
This forbids nice formatting in edition mode with custom CSS.
It seems like a bug to me.

Environment

• Operating system: Mac OS Big Sur 11.2.1

• Obsidian version: v0.10.13

---

Additional information

 

[ryanjamurphy]

@ChezFrancois

• task 1
• task 2
• task 3
  Then, insert a Tab before task 2 for example
• task 1
  →- task 2
• task 3

Can you paste the raw text you’re using? This works for me:

- [ ] Task
    - [ ] Task
- [ ] Task

Note you can surround text in three backticks (```) to show the raw input.

[ChezFrancois]

Yes, it works in the standard Obsidian editor’s UI.

But when you try to apply a CSS snippet to make the appearance of tasks nicer, it doesn’t work. The reason is that sub-tasks are miss-managed by the editor, so CSS can not apply a task format to something which is not any longer identified as such.

Screenshot with just tasks:

Screenshot with a subtask:

With cursor “activating” the line where the subtask is:

[Erisred]

I have an idea as to what’s causing this. You’ll have to contact the authors to verify, but usually they will first remove the default check box, then add their own cool symbol in its place.

Similar to this post about bullet points they will sometimes forget to include all list-item-children in the code.

Can you share the code snippet you are using?

[ChezFrancois]

The entire code is shared in this post:

Typora like custom CSS

Leveraging several proposals to tweak Obsidian and make it behave as nearly as possible from Typora in the edition mode, I came to the following CSS snippet that works wonderfully well, yet staying simple. Use it at your leisure: /* inline formatting, link targets and [[ ]] disappears if not active line*/ div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting, div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-string.cm-url, div:not(.CodeMirror-activeline)>.CodeMirror-line s…

The part related to tasks is hereunder:
/* Checkboxes instead of brackets in edit mode */
div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting-task.cm-meta,
div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting-task.cm-property {
color: transparent;
position: relative;
display: inline !important;
margin-right: -0.1rem;
}

div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting-task.cm-meta:after,
div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting-task.cm-property:after {
content: “○”;
position: absolute;
top: 3px;
left: 0px;
color: rgb(219, 95, 12);
font-size: 18px;
}
div:not(.CodeMirror-activeline)>.CodeMirror-line span.cm-formatting-task.cm-property:after {
content: “✓”;
color: rgb(124, 131, 124) !important;
}
span.cm-formatting-task.cm-property ~ span {
text-decoration: line-through;
color: rgb(124, 131, 124) !important;
}

[pjeby]

You are missing a space between the - and the [ ] (or have a not-recognized-as-whitespace character there). That’s the source of the issue.

You can tell this because with a space, the [ ] gets classes of cm-formatting cm-formatting-task cm-meta, but without a space, the opening bracket gets cm-formatting cm-formatting-link cm-link cm-list-1 cm-hmd-barelink, as shown here.

In other words, this is not an Obsidian bug; it’s an error in the markdown. The space after a list marker is not optional in markdown syntax.

[ChezFrancois]

In the example shown above, there is a normal space in the tasks and in the sub-task. That is not the source of the problem.

First level task is written like this: “-” space “[” space "] and is recognized as a task
Second level task or sub-task is written like this: tab “-” space “[” space "] and is not recognized as a task.

[Erisred]

@ChezFrancois - You definitely have something else affecting this. It could be missing/extra whitespace somewhere in the raw text as @pjeby suggests, but I suspect there’s something in your stylesheet(s) you have not shown us here.

When I add just the snippet you gave to a simple file (using a vault with NO other css or plugins), quite a bit is missing:

However, when adding the entire stylesheet you linked to, things look fine to me:

Basically, I don’t think there’s a bug in Obsidian, I think you have a bug in your stylesheet(s) (assuming the whitespace isn’t the issue).

One last thought - if you are using this snippet, then applying a community theme on top of it, there’s a good chance they are conflicting one another.

[ChezFrancois]

Thanks for sharing this test.
I sliced the stylesheet in small pieces to test their interactions. The problem is more complex than I thought.
I will share my findings and possibly a solution when I will have finished.

[ChezFrancois]

Exploring different options, I discovered that, if, in editor’s parameters, Tab size (number of spaces a tab is equivalent to) is below or equal to 4, checkboxes are displayed correctly:

As soon as this parameter is set at 5 or above, the checkboxes of sub-tasks disappear. Strange?

What is the explanation of that?

[WhiteNoise]

Because the markdown spec is more complicated than it seems. (there is actually a right range of whitespaces, and you go from no task, task, no task).
This is true for lists in general.

I didn’t go too deep into this issue however we are aware that there are bugs in the editor parsing, (there are even bugs in the preview made by remark!).

I am not sure there is bug here, but if there is, it won’t get address until we do an overhaul of the editor.

[pjeby]

After fiddling this for a while, I’m pretty sure that Obsidian is not violating the Commonmark spec. (At least not in any obvious way.)

The issue here is that nested lists are allowed a maximum indent of 3 spaces beyond the width of the parent list item marker (- and a space in this instance). Beyond that, it’s supposed to be considered a code block, at least if there is a blank line above it. However, if there’s no blank line, it fails the Commonmark indented list rule, and falls back to being treated as part of the current paragraph (i.e., the list line above it).

(You can see this more clearly in preview mode, where the contents of the item are wrapped up onto the previous task list line.)

So, I think the short answer to this is, follow Commonmark indentation rules, and you’ll be fine.

[ChezFrancois]

That seems to close the debate effectively. And yes, it makes Markdown more complex than I thought.
Thanks to all respondents who helped sort this mystery!

[ChezFrancois]

One more remark: The current behavior of Obsidian may be consistent with CommonMark indentation rules, but is not with the choice proposed in the Editor’s parameters.
If this parameter can be set anywhere between 2 and 8, nothing should change but the indentation distance. Or a warning should be added, explaining that for a value of 5 or above the behavior of tasks lists will change regarding sub-tasks.

[WhiteNoise]

the editor parmeter is about converting tabs to spaces not about lists and commonmark

[ChezFrancois]

One can use tab to create a sub-point or a sub-task. Then, this parameter has a direct influence on lists.