Named block code fences are colored and indented unexpectedly

[bcmadsen]

I see where the different preview themes are stored, but after reading through the Theme.css and Theme.html files there, I'm not seeing a clear reason for the following behavior. No doubt it's in there somewhere, but I'm not sure where.

```
one
two 
three
```

This shows up in some of the preview themes (e.g., Hipster, Westwind) with the first line colored blue, differently than the second and third lines. Meanwhile:

```java
one
two
three
```

This shows up with all of the lines colored the same. That's actually what I would have expected without the "java" addition. I wouldn't have expected the first line to be blue in either case. But now for the really weird one:

```text
one
two
three
```

To my surprise, this is rendered with the first line indented a space or two -- and also with an unnecessary vertical scroll bar for some reason.

Clearly, something about the HTML/CSS that drives the Preview Themes is treating that first line differently than the others (and adding scrollbars at random too), but can somebody help me see where the styles are that are causing that? No doubt it's right in front of my two eyes, but I'm not seeing the connection between the CSS that I read and the Markdown Monster behavior that I see.

(For extra credit have a look at that last example with either the Github or the Medium Preview Theme. You'll see what I mean when you get there. I'd love to have someone explain that to me. The answer will have to do with Preview Theme styles, I'm sure. But what?)

[RickStrahl]

I agree this isn't ideal but there's some logic behind this based on the JavaScript library used to render code snippets.

The syntax coloring in the the various themes are provided through a third party JavaScript library, HighlightJs and most of the syntax themes are stock themes with a few small style customizations. Each Preview theme uses a specific HighlightJs theme which is determined by the CSS that is referenced.

I think the issues that you see are as follows:

• If you don't specify a language it tries to auto-detect and that produces garbage because it probably can't figure out what language it's dealing with.

• text is not a valid format. Use txt instead.

Overall I don't recommend you use auto-detection - always use a language or txt for no formatting. If you're not sure of what the format is you can use the Toolbar code insertion or alt-c to embed your code and the proper code fencing that should work.

ps. Taking a look at what happens with your code it looks like the auto-detect thinks it's nginx syntax :-)...

Hence the point of using explicit styling.

It looks like the text style should be working - it's a custom language I added:

/ Language: Text Author: rstrahl rstrahl@wwest-wind.com Category: common /

function(hljs) {

return { aliases: ['text','txt','plain','none'] }; }

which is meant to be a no-op. Not sure why it's not picking up the text directive properly. I'll check on that...

[RickStrahl]

Fixed this with a hacky workaround. There appears to be an issue with highlightJs not accepting text and plain as valid syntax and it intercepts. The fix on MM's end is to pre-process the HTML before it's passed to highlightJs and explicitly bypass syntax highlighting and just assign a style.

Fixed in bd551630899ba180473335f5542b19e42a9c4e8d