The CommonMark specification states that list indentation can specified using 1) a fixed number of spaces (1 tab / four spaces) or 2) the width of the list item delimiter plus the number of spaces before the first character of the list item content (referred to as “delimiter-based indentation” moving forward).
## Fixed width indentation (1 tab / 4 spaces) - No indent - First indent (4 spaces) - Second Indent (8 spaces) 1. No indent 1. First indent (4 spaces) 1. Second Indent (8 spaces) ## Delimiter-width indentation - No indent - First indent (2 spaces) - Second Indent (4 spaces) 1. No indent 1. First indent (3 spaces) 1. Second Indent (6 spaces) 001. No indent 001. First indent (5 spaces) 001. Second Indent (10 spaces)
As of v1.0.3, Obsidian renders both indentation styles consistently in reading mode, however in live preview mode there are two inconsistencies:
- The inline
padding-inline-startvalues are different on the
<span class="cm-indent">element is missing when using delimiter width indention.
The result of these issues is that 1) list are rendered inconsistently in live preview based on the indention used and 2) visual indentation guides are not displayed properly when using delimiter-width indentation.
Steps to reproduce
Copy/paste the CommonMark-compliant markdown above into Obsidian.
Note the visual difference in indentation size and incorrect rendering of indention guides in the delimiter-based indention examples:
Open Obsidian’s dev tools, inspect two similar sub lists, and note two inconsistencies described above.
I would expect lists to be rendered consistently regardless of the indentation style used.
- Fixed-width indention style renders properly in reading and live preview mode
- Delimiter-based indention style only renders properly in read mode.
- Operating system: macOS 12.6
- Debug info:
Obsidian version: v1.0.3
Installer version: v1.0.3
Operating system: Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 21.6.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: adapt to system
Community theme: none
Snippets enabled: 7
Restricted mode: off
Plugins installed: 14
Plugins enabled: 14
1: Linter v1.8.0
2: Style Settings v0.4.12
3: Advanced Tables v0.18.0
4: Natural Language Dates v0.6.1
5: Rollover Daily Todos v1.1.3
6: Paste image rename v1.5.0
7: Calendar v1.5.10
8: Periodic Notes v0.0.17
9: Templater v1.16.0
10: File Cleaner v0.1.5
11: Paste URL into selection v1.7.0
12: Note Refactor v1.7.1
13: Sort & Permute lines v0.6.1
14: Obsidian Git v2.12.1
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.
Snippets are all disabled (despite what debug info above states).
Also, here is what the CommonMark authors have to say about fixed-width indention vs delimiter/content-based indentation:
The most important thing to notice is that the position of the text after the list marker determines how much indentation is needed in subsequent blocks in the list item. If the list marker takes up two spaces of indentation, and there are three spaces between the list marker and the next character other than a space or tab, then blocks must be indented five spaces in order to fall under the list item.
The strategy here is to let the width and indentation of the list marker determine the indentation necessary for blocks to fall under the list item, rather than having a fixed and arbitrary number.
This rule is superior, we claim, to any rule requiring a fixed level of indentation from the margin. The four-space rule is clear but unnatural.