Does not work in html codeblocks?

[crankedguy]

This plugin is really great, I love the configurability and everything about it.
But, after installing, and unless I oversaw something, which I am afraid I did not, this does not work for html codeblocks, right?

So either:

<pre><code>...</code></pre> or
<code>...</code> for inline

I have, for good and also technically necessary reasons, on nearly every note html (code)blocks in the markdown files. The html codeblocks are always rendered vanilla, no matter what I tried.
This, sadly, would render the plugin completely useless for me, as I would have 1000s of different styled codeblocks, which makes your brain completely tick out over the different styled and highlighted codeblocks.

Can you confirm my assumption that it does not work in any way for html codeblocks, and if it does not, is it planned maybe?

Thanks

[mugiwara85]

@crankedguy Sorry, but I don't really understand what you mean by "the html codeblocks are always rendered vanilla"? Do you mean that the background color is always the same for html codeblocks? Even in dark mode? If yes, then do you have some custom css set? Or something where you might have set the background color for code blocks? Could you please try in a new vault, without any custom css and any other plugin, to see if the problem remains. If not, please explain, what exactly you mean.

[crankedguy]

@mugiwara85 I don't know honestly on how I should explain it any clearer (not meant in a bad way!)

All the code enwrapped in backticks is properly styled by your plugin, all code that is in html codeblocks, either "pre/code" combination or "code" alone is vanilla (vanilla = standard behavior aka this code is not touched by your plugin).

So:
```python
a = 0
print(a)
```
is properly styled with your plugin, while

<pre><code class="language-python">
a = 0
print(a)
</code></pre>

is styled natively by Obsidian, it is not touched/handled by the plugin, and the codeblock(s) look the same as without the plugin installed. Both are completely valid codeblocks in terms of Obsidian.
Is this better understandable for you?

[mugiwara85]

@crankedguy Ahh that's what you mean. It works for me

Did you by any chance set the html language as an exception here?

That is the only thing I could think on.

Send me your data.json file please. Maybe I can reproduce it that way.

[crankedguy]

no I did not set it as an exception, but did you place your example in backticks with "html" for github here, or do you expect it to be like that in Obsidian?
I speak of clear html code, not wrapped in backticks, so in the Obsidian file you have really only

<pre><code class="language-python">
a = 0
print(a)
</code></pre>

there is nothing enclosed in backticks around, that makes no sense, as it is (real) html code. no I have not excluded html, that list is also only for identifiers. Your plugin would have to realize <pre><code>... or <code>... as actual code(block), not only backticks.
I think this is not the case right?

[crankedguy]

is this clearer for you on what happens?

[mugiwara85]

Ah that's it. Yeah, that won't work that way unfortunately. The plugin only handles inline code e.g. `inline code` (written in single backticks), or fenced code. The opening and closing line must be either three backticks, or three ~ sign.

Your case is handled as normal text.
As a background info: this is because if you create a code block, then Obsidian adds additional classes to the code block. The plugin is looking for those classes. It actually really complicated to identify code blocks.

Why do you write your code this way and not as fenced code blocks?

[crankedguy]

this has technical reasons, and would be quite a bit too long to explain here :)

I use both formats (or all 4 if you count inline/single backticks along), also in the same file.
As both are completely valid as "code" for Obsidian because it interprets html code as is. As you can see it is perfectly formatted as codeblock, just not touched by your plugin (which is clear now because you don't recognize it as code in the plugin).
That is too bad, I would have loved to use it, but that way it makes no sense, and I sadly have no time to sit down and extend it myself.

But hey, that's life, you cannot have everything, every time.
Thanks for the quick and friendly replies. Plugin is really great otherwise as said!

[mugiwara85]

Is only php like this? I mean are there any other languages that would work similarly when not inside a fenced code block?
I can have a look at it, how complicated it would be to make this case also work, but I am not promising anything. It could take a little longer than usual though, as I have a lot of work unfortunately. Does this work for you?

[crankedguy]

no it is not only php or python, it affects every language there is. You can see the "pre/code" construct as equivalent to three backticks and "code" to only a single backtick. This is how Obsidian handles it natively as said. It treats "pre/code" as full-fledged codeblocks and highlights them accordingly, same as it would do with a markdown codeblock with three backticks.
The language is usually defined by "class=language-" in the "code" element, not in the "pre".

So a codeblock is essentially like I already wrote above:

<pre><code class="language-<languagename, i.e python>">...
your code...
...
</code></pre>

and inline code is usually

<code>this is an inline codeblock</code>

You can also see in the inspector that in the end Obsidian converts markdown blocks with backticks to exactly those elements, As in the end it is native HTML code, which Obsidian has to convert to for rendering anyways. The difference here is that you just write this code directly into the file, so Obsidian takes it literally. The functionality itself is completely native to Obsidian.

Yea, sure, I would be happy if the plugin had the functionality, and you don't have to promise anything just for me. If you decide to do it you would have a more "complete" plugin in the end, as this is not something exotic. In fact your plugin now only treats half of the native functionality of Obsidian for codeblock handling (but this is not to be taken as offense or accusation of course),

I have the thread here subscribed, if you have any news, or skip it (which is also ok of course), let me know.
Thanks!

[mugiwara85]

Just one question. Where/how would you define the parameters? Currently you can define them after the 3 backticks. But if you just write <pre><code class="language-<languagename, i.e python>">... Where would you defint the parameters?

[crankedguy]

You mean the special parameters of/for the plugin? If yes, a possibility would be data-* attributes, see e.g.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/data-*

so as an example:

<pre><code class="language-python" data-cbc="<your parameters>">...
your code...
...
</code></pre>

or do you mean something else?

[mugiwara85]

yes, I meant those.
To be hones, I didn't even know that Obsidian can do this 😆
Ok, I'll look into it, and get back to you later.

[crankedguy]

Obsidian's render is built on that :)
Yea, no rush, thanks for considering it in the first place

[crankedguy]

what I am not 100% sure tho is if you can read those data-* attributes (i.e. if you have access to them, but that should be easy to check). In a browser that is how you could approach it, I don't know if Obsidian has any restrictions regarding this, just as a hint.
That would be the most straight forward way at least for such things as the pars for the plugin