Unexpected Status Type of the Sub Tasks in CSS

[ArchiDog1998]

Please check that this issue hasn't been reported before.

• I searched previous Bug Reports didn't find any similar reports.

Steps to reproduce

CSS snippets learned from styling guide

.task-list-item[data-task-status-type="TODO"] .task-due[data-task-due="today"] span,
.task-list-item[data-task-status-type="IN_PROGRESS"] .task-due[data-task-due="today"] span {
    background: #556B2F;
    border-radius: 10px;
    margin: 0px 5px;
    padding: 2px 8px 2px 0px;
}

Write mark down like this
Today is 2024-12-04

- [ ] Test1 📅 2024-12-04
	- [x] Sub Task 📅 2024-12-04 ✅ 2024-12-04

Well I think that none of them should be changed. If the sub tasks are done, they are done.

Expected Behavior

The Test1 task should be highlight by the way, I just don't know how to make it.

Current behaviour

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Obsidian Version

1.77

Tasks Plugin Version

7.14.0

Checks

• I have tried it with all other plugins disabled and the error still occurs

Possible solution

Just a logical thing, not hard to fix. Thanks a lot!

[claremacrae]

Thanks for logging this.

I will have to experiment with this, but I think the behaviour is doing what the CSS says - and in fact the CSS will likely need to be updated for support of nested tasks.

[claremacrae]

Tasks 7.14.0

This is my test file:

- [ ] #task Test1 📅 2024-12-04
	- [x] #task Sub Task 📅 2024-12-04 ✅ 2024-12-04

```tasks
path includes {{query.file.path}}
show tree
```

And this is what I see - so the problem applies to both Reading Mode, and search results, when show tree is used...

Tasks 7.11.1 - before show tree changes

With pre-show tree code, I had to comment out that instruction, but the problem still exists in Reading Mode:

Tasks 3.0.0 - when this CSS feature was introduced

I had to change the test file to:

- [ ] #task Test1 📅 2024-12-04
	- [x] #task Sub Task 📅 2024-12-04 ✅ 2024-12-04

```tasks
path includes 3219
#show tree
```

And the Reading mode result is the same:

Summary

This isn't actually a new problem - it has existed since the 3.0.0 release on Apr 2, 2023...

As far as I recall, this is the first report of it.

[claremacrae]

As far as I can see from testing, the nested tasks inherit the styles of the outer tasks.

The only workaround I can find is to add specific styles for the completed tasks, which will be used in preference to the outer styles...

This seems to work with your example:

.task-list-item[data-task-status-type="TODO"] .task-due[data-task-due="today"] span,
.task-list-item[data-task-status-type="IN_PROGRESS"] .task-due[data-task-due="today"] span {
    background: #556B2F;
    border-radius: 10px;
    margin: 0px 5px;
    padding: 2px 8px 2px 0px;
}

.task-list-item[data-task-status-type="DONE"] .task-due[data-task-due="today"] span,
.task-list-item[data-task-status-type="CANCELLED"] .task-due[data-task-due="today"] span {
    background: unset;
    border-radius: unset;
    margin: unset;
    padding: unset;
}

[claremacrae]

Hi again @esm7 ... I would greatly welcome any suggestions on the above, if you have time, please....

[ArchiDog1998]

As far as I can see from testing, the nested tasks inherit the styles of the outer tasks.

The only workaround I can find is to add specific styles for the completed tasks, which will be used in preference to the outer styles...

This seems to work with your example:

.task-list-item[data-task-status-type="TODO"] .task-due[data-task-due="today"] span,
.task-list-item[data-task-status-type="IN_PROGRESS"] .task-due[data-task-due="today"] span {
    background: #556B2F;
    border-radius: 10px;
    margin: 0px 5px;
    padding: 2px 8px 2px 0px;
}

.task-list-item[data-task-status-type="DONE"] .task-due[data-task-due="today"] span,
.task-list-item[data-task-status-type="CANCELLED"] .task-due[data-task-due="today"] span {
    background: unset;
    border-radius: unset;
    margin: unset;
    padding: unset;
}

Thanks! It works on my machine! This is a nice temporary fix with my example.

[esm7]

The problem is that the space operator between .task-list-item[data-task-status-type="TODO"] and .task-due[data-task-due="today"] can go many levels down the tree and apply to multiple tasks this way. My preferred solution here would be to selectively go down the element tree by adding > span, so further space operators won't reach the nested task:

.task-list-item[data-task-status-type="TODO"] > span .task-due[data-task-due="today"] span,

@claremacrae funny how only two days ago I thought that using the direct ancestor operator is very niche. I was not considering the case of nested tasks!

[ArchiDog1998]

Oh! I see, thanks a lot!

One more thing, I hope you guys could update this tutorial about styling. This will help the others who want to do similar things like me.

[claremacrae]

Thanks @esm7 - I had tried adding > before the original span in the CSS - I hadn’t thought of adding a whole new span!

Yes, of course I will update the documentation - however I expect other examples will also need updating, not just this one. So it will need a chunk of free time to do all the experimenting and editing.

[esm7]

Perhaps the best approach would be to keep the examples as they are, just add a note about the effect on nested tasks, with an example how to mitigate that.
Because:

1. I'm sure there are cases on which the inheritance of styling is a positive expected result,
2. The extra complexity would make it harder to understand the bigger ideas of how these snippets are built, while being irrelevant to a big portion of the users.

[claremacrae]

Thanks for the suggestion.

I’ll think about it.

I think the examples that style particular fields may merit having the span added to avoid them misleadingly highlighting other values. Will see what I can do.