New Renderer Code Highlighting

[calculuschild]

How should the Code in backticks be handled? Do we

1. just display literal characters literal {{span stuff}}
2. Allow our mustache spans to have custom code highlighting?

[Gazook89]

If it's possible to highlight syntax without doing custom code highlighting, we should do that. All of my custom code highlighting (in the Share link in your post) is just to get it to match the Editing pane....if that highlighting can be done behind the scenes with a plugin or JS then we don't have to worry about code/markdown inside <code> blocks.

However, setting that up behind the scenes is beyond my technical ability, so I can't contribute to that effort, and really have no idea if it's possible (even if I suspect it is).

[AlexeySachkov]

How should the Code in backticks be handled?

What is the expected usage model of backticks in brews? Do we have them used already somewhere or we just want to propose them as additional syntax feature for doing something?

[calculuschild]

Good questions, and my apologies for the wall of text as I respond to your points:

do we really need to support an inline code?

If we are going to support block code, I would like to support inline code as well. It might not be a common thing in a D&D book, but we have had requests for it often enough. Anybody who uses block code is likely going to be confused when inline code doesn't work.

map it to some new type of styling

A lot of the motivation for the V3 renderer is moving away from weird Markdown combinations to generate D&D styling. It makes sense to have <hr> generate the divider lines in a Monster stat block, and having ### Abilities generate larger text in a sub-title or sub-heading in a note. It doesn't make as much sense to hijack a series of

___
___
> # Title
> text

to signal the start of a Monster block. This makes CSS rules large and complicated, and adding a new element requires lots of overlapping rules and edge cases with !important, especially if you want to customize a style or make any tweaks. Similarly, using blockquotes for Monster blocks, code blocks for notes, inline code for something else, quickly means we run out of available markdown syntax to handle all the different cases. This is why there is currently an odd mixture of Pure Markdown elements in some snippets, and Divs in others. Instead, two goal with V3 are these:

1. All unique code blocks will be defined by a DIV class (using {{) rather than some confusing arbitrary combination of HTML elements
2. All markdown syntax will be used logically, as it was originally intended, as much as possible. *text* will create italics. **text** will create bold. *text* will not italicize in one case, but create blue text in another case. For instance, some of the text in the Monster stat block is black, and some is red, depending on its location, and that's fine to be all generated using *text*, as long as it is also italicized.

we could replace our {{ }} syntax for spans with inline code syntax

I disagree. To me, it makes more sense that the syntax would be similar between divs and spans. And then I just don't like the idea of hijacking an existing syntax for something it is not meant for. It just makes the CSS convoluted and illogical.

I don't quite understand why we have decided to go with {{ }} and not with fenced divs,

There was a lot of discussion on this a while back. If I remember, you were in some of those discussions as well (I think we can dig them up from the Gitter/ Github issues if we want). Essentially, the conclusion was this:

• The fenced Divs from Pandoc are not official Markdown spec, or widely adopted
• Discussions on the actual CommonMark blog/development boards are in favor of a single {.class} or double curly brace syntax, so this is closer to the potential standard that may eventually develop
• For non-coders, {{, }} is easier to visualize where a section starts and stops, where :::: is either a start or end, and nesting becomes even more convoluted.
• {{ is easier to implement on the Homebrewery
• {{ allows a similar syntax for spans. Fenced divs do not (Pandoc also resorts to brackets in this case).

[AlexeySachkov]

If we are going to support block code, I would like to support inline code as well. It might not be a common thing in a D&D book, but we have had requests for it often enough. Anybody who uses block code is likely going to be confused when inline code doesn't work.

Having user requests for sure motivates this enough. Do we have more details, i.e. what should inline code block do? Is it expected to be its regular job (like monospaced text, probably highlighted by some separate background) or something custom?

map it to some new type of styling
A lot of the motivation for the V3 renderer is moving away from weird Markdown combinations to generate D&D styling.

I probably meant that if there is some widely-used combination of styles (like this word should be rendered using a different font, color and size) then we could use inline code block to represent that style in addition to regular bold and italic.

In total I imagine a few use-cases:

1. inline code block is not highlighted in any way, but just turns text into some new font, which will be used for different formulas like d20+3
2. inline code block is highlighted and it is used to show code snippets or hotkeys like here

Essentially, the conclusion was this:

Thanks for that summary, I missed at least half of those points from previous discussions. It all makes sense

[calculuschild]

what should inline code block do? Is it expected to be its regular job

Yes. The intention is to use it as in option 2 that you listed from GMBinder

different formulas like d20+3

Interesting idea. Do we have any examples from the D&D manuals of some standard styling for this type of thing? I'm still not sure I would want to repurpose inline code for that, but I am more open to this if it is an existing style in the books.

[AlexeySachkov]

Do we have any examples from the D&D manuals of some standard styling for this type of thing? I'm still not sure I would want to repurpose inline code for that, but I am more open to this if it is an existing style in the books.

I was looking at various rulebook pictures from Pinterest for a few minutes and haven't found anything like this. In all cases they were just using an italic font

[calculuschild]

Alright. In that case, I'd like to move forward reserving backticks for inline code, but if we come across any other styling that might need some syntax we can revisit this.

[ericscheid]

A reminder: content doesn't have to be within a <code> block for it to appear styled as code.

<style>
.code { font-family: monotype; /* etc */}
.bold { font-weight: bold; color: black; }
</style>

{{.code Here is some plain text that looks like code. This {{.bold `**word**`}} is bold.}}

[calculuschild]

Correct. And maybe we leave this as the option for people who want to style their code with {{ blocks?

But for the purposes of people wanting to display unstyled code, I would prefer we give them the option of the standard code syntax, rather than steal the code syntax to use for something unrelated.

[Gazook89]

I think using ticks/code tags does more than just styling right? It negates rendering of html. So just using styled divs/curly brackets isn't the same. Correct me if I'm wrong.

I believe we should stick closely to regular use of markdown where possible. The main goal it seems of v3 is to fix the errors of the past, when it comes to funky uses of markdown. If, like the curly brackets, we need additional functionality we come up a new syntax.