Why don't tabbed code blocks render in Reading mode?

I’ve noticed when I place a leading tab or four spaces before a line, it indents the block similarly to a block quote but without the line on the margin. I had to dig a bit to find that this is officially the Markdown syntax for a code block—I only knew about the backtick syntax for fenced code blocks.

That’s fine, but in the default Obsidian theme, tabbed code blocks only render in live preview—they’re ignored in reading mode. Even in live preview, the font remains the same rather than changing to monospaced. This confuses me.

Just for giggles, lets see how the forum Markdown processor renders them.

This is a blockquote (which my spellchecker keeps trying to turn into two words). This is normal text (other than being quoted), so it should wrap long lines, which this Markdown processor does to its heart’s content.

I can't type a tab in this editor, so I used four spaces. This should be a code block, and I'll keep typing nonsense until it wraps, to see how it formats multiple lines. Interestingly enough, I can see in the preview that this markdown processor *does* change to monospaced type and doesn't wrap the text.
This is a new line, preceded by four spaces, and it renders as a second line in the code block.
This is supposed to be a fenced code block, because it’s formatted with three backticks befor and after, and it does change to a block with monospaced type. It should ignore this *italic* formatting, and it probably shouldn’t wrap lines, at least in Reader mode.
This is a second line in the fenced code block, with no blank line between. It renders correctly as a second line of code.

Those both work correctly here but not in Obsidian—it renders both inline code and fenced code blocks in a monospaced font, and it ignores italic formatting, but it wraps the text. This processor renders the text in a single, scrolling line, which seems more appropriate or accurate.

My question is really about style and usage rather than formal syntax—do tabbed code blocks not get any love? Or are they used as a hack for other formatting, leaving code to the backticks? Do most Obsidian themes render them correctly in Reader view? It seems strange the default theme doesn’t.

Not a big deal—it just makes me wonder.

Although looking a bit different, indented/tabbed code blocks should be fine in the editor and Reading view if they are separated by blank lines above and below.

source mode | live preview | reading view

The first section is what usually trips people up; not that the indented text isn’t a code block, but that the indent is removed/vanishes when switching to Reading view, exporting a PDF, etc.

It’s just one big p (paragraph) when rendered:


For the wrapping… maybe a style choice? You can use this CSS snippet to change the behavior, but I did notice it’s all on one line compared to your forum examples here.

.markdown-rendered pre {
    white-space: nowrap;
}

Obsidian_1kOC53br4N

Thanks for the clarification. I’ll have to try your snippet—I also checked my snippets to make sure they weren’t bunging up the rendering. I haven’t messed with the theme CSS at all. I’ve made extensive edits to my Typora themes, but I’m still learning how Obsidian CSS works.

I did have blank lines above and below the code block—you can see my original file here:

If Obsidian (or the theme) doesn’t indent or change the font or turn off wrapping, how is it different from normal text? I guess it respects line breaks, but the default theme doesn’t even respect tabs within the block (I think it respects less than four leading spaces). And if it renders as one big <p> tag, then you could style the block with local CSS. BTW, I had added a .poetry css class to the document, but I confirmed that wasn’t affecting the formatting (I turned off my poetry snippet).

I’ll have to play with it more, but with the theme I’m using, it seems like it’s wasting the Markdown syntax for a code block.

I looked at the original file you attached and apologize if I’m misunderstanding, but I think what you’re looking for can be described by this:

```
lorem
	ipsum
dolor
```

The indentation inside a code block is what’s preserved. Same for other white space.

More visual examples:

```
text
	tab
text
 one space
  two spaces
   three spaces
                    twenty spaces
text
			three tabs
```

Sorry—my example file was all over the place because I was testing all the permutations I could think of. I really had two questions:

  1. How do I indent/format poetry?
  2. Why are tabbed code blocks apparently ignored in Reader mode?

This is Markdown, so there isn’t a simple answer to #1—I’ll just have to apply a class in the YAML and mess with the CSS and available syntax until I find something that works for me. It’s not a big deal—I just enjoy making computers sit up and do tricks.

Regarding #2, I just figured out that I was bunging up the syntax (see below).

This is tangentially related to a work project where I’m using Markdown to write technical documentation and applying CSS in our knowledge base editor (it’s the TinyMCE embedded editor in ServiceNow). I’ve got that pretty well locked in except for tables and image formatting, which I need to clean up in TinyMCE because Markdown doesn’t provide the level of control I need for those. I’m using it to generate a basic HTML structure, intentionally without any formatting, which is harder than you might think because most apps want to add formatting to the HTML. It took some digging, but I’ve found a few ways to get plain vanilla HTML—now I just have to figure out how my coworkers can do that in an app that is readily available within our IT shop.

I just looked at my file again, and you were right—I’d placed a blank line after the code block but not before. I added a blank line before, and bingo! It worked!

This is indented with spaces
    This is indented further

Not sure what’s happening here—looks like one code block with different levels of indent.

This is indented

	This is double indented

I also fixed my blockquote syntax—it appears that tabbed or spaced indents are ignored within the blockquote, but if I nest block quotes with two >> marks, that works.

This is a blockquote
This is a second line
This is indented within a blockquote (indent is ignored)

This is a blockquote
This is a second line

This is a nested blockquote

If I add a blank line before the indent nested within the blockquote, it renders correctly as a code block within the blockquote. I had to substitute four spaces for the tab to make it work here.

This is a blockquote
This is a second line

This is indented within a blockquote

If you start a thread about this, feel free to ping me in a comment to call my attention to it (like so: @CawlinTeffid).

Check out my wiki docs and indentation
If you’re comfortable to change themes, feel free to try out my theme, just search for «Dune» under Obsidian settings>appearance>themes>manage:slightly_smiling_face:

@Jopp @CawlinTeffid Yup—poetry formatting seems to be an evergreen topic. :smirking_face: I’d be happy to dig into it for the technical challenge, but it’s not a big need. I’ve been writing a lot more prose/memoir/journaling sort of stuff and would like to branch into poetry at some point.

Since Markdown is deliberately formatting agnostic and generates structural rather than typographic tags, poetry syntax is probably out of scope. That said, one could define a standard way to denote titles, stanzas, and line breaks, then create CSS to format those the way you want to. It’s simple to set a CSS class in YAML to let Obsidian and/or your output processor know what formatting to use. Some creative formatting will always require manual intervention, but a lot could be done with standard formats.

CSS can be very handy to support your writing experience, since “styling” isn’t just about eye candies.

Since Obsidian is a good basis for all kinds of studies, plugins and even themes can enrich, expand significantly how you work with Obsidian and even adapt to your writing “style”, which is an important point. Standard tools are very useful, but still forever defaults.

Of course, themes are less powerful than plugins, so you’ll need to add some cssclasses for “the magic” to work, or to toggle some buttons. (Buttons, thanks to the “Style Settings” plugin by mgmeyers )
Like with everything, I suggest anymore to pick only the features you’re most interested in and try them out to see immediate results.

Some plugins and themes get updates on the long run, some not. Since I use my theme too, I’ll continue to update the public version as long as I’m using Obsidian. :slightly_smiling_face:

BTW, my theme supports indentation as well, I’ve updated my previous posting or follow this link if you read answers through email.

@Jopp Good thoughts. I’ve done enough web design to comfortable with basic CSS and able to research more advanced features. I agree formatting is more than just eye candy—I worked in design studios for a decade (I was always the geek in the studio), and formatting is a large factor in clear communication. I also just like stuff that looks good. (I’m obsessed with finding ways to use Optima in on my onscreen reading applications).

I looked briefly at your Dune theme but haven’t had a chance to try it out yet—I plan to soon. I also went through the five or so themes I’d loaded in the past and rediscovered how many variables the Minimal theme exposes to the Style Settings plugin—that’s a great way to format text without CSS. It even allows saved configurations, so it’s easy to switch for different contexts. I prefer a fairly minimal but attractive (i.e. clean) writing environment, as I am easily distracted.

@CawlinTeffid I think I will take you up on your suggestion of starting a poetry topic. Even if I’m not a poet (yet), it could be helpful to a lot of other folks.

@Jopp @CawlinTeffid @dawni @ariehen

I started a poetry-specific topic here to discuss advanced formatting techniques in general and poetry in particular. I put it in Meta to make it as open as possible—from what I’ve seen here and in other forums, poetry formatting is a common issue. I’m guessing it’s a small percentage of users, but they are passionate. :wink:

Please feel free to contribute!