(Edited title:) Different Parts of List Get Hidden When Folded in Reading vs Editing Mode

[jeetsukumaran]

What I’m trying to do

Here is a note:

- List item 1 
    - Sublist item 1
    - Sublist item 2
- List item 2
  The quick brown fox jumps over the lazy dog.
  This paragraph stays visible when parent list item is collapsed
    - Sublist item 1 gets hidden when parent list is collaped
    - Sublist item 2
    
  etc.
- List item 3
  The quick brown fox jumps over the lazy dog.
  This paragraph stays visible when parent list item is collapsed
  - L1 This gets folded away
  - L2 This gets folded away
  - L3
    This gets folded away
- List item  4
    - Sublist item 1
    - Sublist item 2
- List item 5
  > [!info]+ Example 1 remains visible
  > - Callout list item 1
  >   - sub1 remains visible
  >   - sub2 remains visible

Here is how it looks like in the Obsidian sandbox vault source view with all the list items collapsed:

Here is how it looks like in the Obsidian sandbox vault reading view with all the list items collapsed:

As can be seen while all the sublist items fold away, the main text content of parent list item remains visible.

It seems like the editing view folds the entire list item away and swaps in just the first line, while the reading view hides the subitems but everything in the primary item scope remains visible.

I have three questions:

(1) Is this disparity in presentation a feature or a bug?
(2) Either way, am I correctly scoping the non-list /sublist content?
(3) Is there way I can get Obsidian reading view to look like the editing view when everything is folded, i.e., just the first line standing in for the rest of the item, including non-list content?

[CawlinTeffid]

I don’t see the behavior you describe with that example. Everything collapses as you’d expect.

But also:

Paragraphs in Markdown are set off by blank lines, so the items you call paragraphs in your example aren’t paragraphs.

Multi line content in a list item needs to be indented under the list item by 4 spaces or 1 tab. So:

- List item 2

    The quick brown fox jumps over the lazy dog.

    This paragraph doesn't stay visible when parent list item is collapsed

    - Sublist item 1 gets hidden when parent list is collaped
    - Sublist item 2

Reading view doesn’t put a blank line between the last paragraph and sublist item 1, even if you put blank lines between sublist items. I’m note sure why that is.

If you want line breaks instead of paragraphs, just remove the blank lines from the above. Markdown actually requires two spaces at the end of a line to mark a line break, and Commonmark (the carefully specified version of Markdown which Obsidian uses as it’s starting point) allows a backslash instead of the 2 spaces, but Obsidian by default treats all newlines as line breaks. The standard behavior can be enabled by turning in Settings > Editor Strict line breaks. This doesn’t seem to make a difference in this case, and the shorter indentation in your example doesn’t seem to matter either, in my testing.

[jeetsukumaran]

Thanks.

Would you mind posting a screenshot of how the example you posted looks in your vault with the outermost list item collapsed?

Mine looks like this in the sandbox vault:

(It looks the same in my main vault).

Specifically, the difference in what is collapsed in edit mode (left) vs. reading mode (right).

The note content is exactly what you posted above.

(p.s., I’ve edited the title to reflect the other part of my question, now that you @CawlinTeffid have kindly provided guidance on the first part (i.e., how to do the multiple part list item).

[CawlinTeffid]

Ah, i had only checked Live Preview. I see the difference in Reading View. It looks like Live Preview folds everything under the first line of the list item, while Reading View folds only the sub-lists.

It makes sense that Reading View doesn’t hide the paragraphs because they are part of the list item. But I could see either behavior being desirable, and ideally both views should behave the same.

It’s expected that Live Preview sometimes differs from Reading View. I think they use different rendering engines, and in any case Reading View is more proper HTML while Live Preview, which does its best to render atop an editor, is structured as a bunch of lines.

But in this case I think it’s worth filing a bug report or feature request (not sure which the team will consider it, but it can be moved to the right place).

[jeetsukumaran]

Thanks!

That clears it up. I’ll put together either an FR or bug as you suggest. Appreciate you taking the time to look into this.