Steps to reproduce
-
Run the command Open sandbox vault.
-
Create a new note.
-
Paste these seven lines:
- [ ] 1 - [ ] 1. - [ ] 1.1 - [ ] 1. text - [ ] 1) text - [ ] - bullet - [ ] > quote -
Look at the note in Live Preview.
-
Switch the same note to Reading view.
Did you read and follow the Troubleshooting Guide ? [Yes/No]
Yes. Reproduced in the Sandbox vault: restricted mode on, no community theme, no snippets, official macOS installer.
Expected result
All seven lines should stay flat — one task list item each, with everything after the [ ] marker treated as inline text. The task marker already consumed the start of the paragraph, so what follows is no longer at a position where a block can start.
That is what Live Preview does, and it matches GFM. GitHub’s Markdown API returns a single flat <ul> for the same input, with no nested list or blockquote anywhere:
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" disabled> 1</li>
<li class="task-list-item"><input type="checkbox" disabled> 1.</li>
<li class="task-list-item"><input type="checkbox" disabled> 1.1</li>
<li class="task-list-item"><input type="checkbox" disabled> 1. text</li>
<li class="task-list-item"><input type="checkbox" disabled> 1) text</li>
<li class="task-list-item"><input type="checkbox" disabled> - bullet</li>
<li class="task-list-item"><input type="checkbox" disabled> > quote</li>
</ul>
Actual result
Reading view re-parses the text after the task marker as block-level markdown. When that text starts with something that looks like a block construct, it becomes a nested block: the checkbox is left alone on its own line, and the content is pushed to the next line, indented underneath it.
| Input | Live Preview | Reading view |
|---|---|---|
- [ ] 1 |
flat | flat |
- [ ] 1. |
flat | nested ordered list |
- [ ] 1.1 |
flat | flat |
- [ ] 1. text |
flat | nested ordered list |
- [ ] 1) text |
flat | nested ordered list |
- [ ] - bullet |
flat | nested bullet list |
- [ ] > quote |
flat | nested blockquote |
The 1) text row is the clearest evidence that a real list is being constructed rather than text being reflowed: the input uses ), but Reading view displays 1.. The delimiter is no longer literal text — it has become an actual ordered list marker, rendered with the list style.
Rows 1 and 3 stay flat because 1 and 1.1 are not valid list markers. So the trigger is exactly the CommonMark list-marker pattern: a marker followed by a space or the end of the line. Blockquotes are affected too, so this is not specific to lists.
Environment
SYSTEM INFO:
Obsidian version: 1.14.0
Installer version: 1.12.7
Operating system: Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041 25.2.0
Login status: logged in
Language: zh
Catalyst license: insider
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Additional information
Tested on 1.14.0 early access. I have not checked whether 1.13.7 behaves the same way, so I can’t say whether this is new in 1.14.0 or long-standing. Nothing in the 1.14.0 release notes looks related to reading view list parsing.
Live Preview — all seven flat, correct:
Reading view — five of seven nested, incorrect:
