Support multiple classes for fenced code blocks

[nsheff]

Right now, fenced code blocks can be assigned a class (which is typically used to define the language). But it is impossible to assign more than one class.

You may want to do this, for example, to distinguish input code blocks from output code blocks in a vignette. Right now, if you try to define multiple classes in a markdown fence block, using {.class1 .class2}, the HTML is not parsed correctly as a code block.

For a use case, see: mkdocs/mkdocs#1720

You may want to say: {.python .inputblock} or {.bash .outputblock} to add a second layer of distinguishing code blocks.

[waylan]

We should probably add support for this to bring our extension inline with PHP Markdown Extra's extension. A discussion of (and the code for) that implementation can be found at michelf/php-markdown#7.

[facelessuser]

So it seems that .classes and #id are allowed in fenced blocks over at PHP Markdown. They threw out attributes from what I can tell. I know Python Markdown allows other options via key="value" for settings.

Am I to assume the idea is to allow these all to be intermingled?

```language .class #id option="value" .more-classes
content
```

Or to assume that classes and ids must come before options?

```language .class #id .more-classes option="value"
content
```

It's a small thing, but important to note when we are deciding how to refactor this to support such behavior.

[waylan]

I know Python Markdown allows other options via key="value" for settings.

Right. I forgot about that. Thanks for the reminder.

allow these all to be intermingled?

Good question. I'm not sure what the best approach is here.

I suppose that this is a significant factor in why we haven't yet added support. There are a lot of moving parts between settings which control the highlighter (Pygments) and attributes to the HTML which provide CSS hooks.

[facelessuser]

I don't think it will too hard to implement, but we definitely need to clearly define how we want it to look. I personally prefer that the style stuff comes first, but that is more of a preference than it is something with solid reasons behind it 🤷‍♂️ .

[waylan]

There are two extensions at work here. The fenced_code extension, which assigns the classes/id to the HTML elements and code_hilite, which handles code highlighting. I'm thinking there needs to be an obvious separation between the two, but what that separation should be is not clear.

[waylan]

I think perhaps the best approach here is to use .class and #id for attributes on the generated HTML elements (with .class .otherclass for more than one class). Then key=value pairs should be reserved for codehilight options only. I don't think it matters what order the various pieces are listed in, but in the docs we probably want to be consistent.

But how do we determine which "class" designates the language? The first .class in the list? Whichever one is prepended with language- (for example .language-python). I think probably we can support both. Perhaps something like this: If a single string (with or without a dot), use that, else if a .language-* class is defined, use that, else if the first item is a dot class, use that, else no language is defined.