Fenced block but not fenced code block


#1

Although I am a programmer and often use the fenced code block, I am also working with a team on a CMS where people write articles that have nothing to do with coding. Instead, we often would like to use an inset with a quote or setlist of the songs a band played or the difference between the answers and questions in an interview.

I know Markdown (and ParseDown and the likes) and the CommonMark are supposed to be generic, but objectively speaking (also when trying to explain to non-programmers), the fenced code block is rather specific to coding.

I am working on an extension of ParseDown to make this work but would love to see this picked up in a broader sense.

At the moment I picked three dots plus a class name as the format. It’s a block so needs to be closed as well. Examples:

... setlist
Song 1
Another song
...
... question
How are you?
...
... answer
OK, thanks.
...

My team members who are not programmers understand this format and are happy to work with it. It offers them just enough to help the editors out and make the article readable.

From a technical point of view I would prefer this, since the regular fenced code block always produces a <code> tag. We could use fenced code blocks with a class and in CSS negate the monospaced font settings.

Another point of view could be to let the fenced code block not produce a <code> tag but a <div>. There are indeed one or two examples where I would need a monospaced block but that could be solved by adding a class to the <div>.

So, I am interested in learning what others think of this or how others would solve this.


#2

Using > will create <blockquote> elements that are appropriate for quotes.

As far as other elements, there are a number of other proposed extensions.


This one covers attributes:


This one covers a generic block syntax


This one covers generic plugins


This one covers <aside>


None are official yet. They’re all at the discussion point, and there are other proposals. I recommend reading through everything that’s been proposed to see if your syntax fits in with one of these previously discussed styles. It also wouldn’t hurt to add your voice to the conversation, especially if you’re an implementer.

History is made by those who show up

In this case, the spec is really made by those who implement it. That’s why there’s so much credence given to existing implementations (such as testing via Babelmark).

That’s not to say you should run off and cowboy code your way to an inconsistent implementation, but trialing one of the generic syntaxes would help as a test case for what works and what doesn’t.


#3

Excellent reply, thanks! I think especially the BLock Directives extension suggestions comes close to what I think would be useful. I searched through the topics before I posted and that one didn’t come up, I must have missed it.

I hear you regarding tests and trials. I am a programmer but when something has been done before why should I do it again? (Well after something is in CommonMark I still have to wait for the implementation…) I am interested in helping out so will check the topics you mention.

Cheers!


#4

You can also check the overview of proposed extension at the wiki.


#5

Looking at what comes closest to what CommonMark is now and the easiest to implement what I need would be the attributes on a blockquote or aside. Both are not part of CommonMark right now so I need an extension for that.

Easiest for our writers would be something like this:

> .setlist

I think I can teach them to follow a more common way to use attributes:

> {.setlist}

If the parser would then use <div class="setlist"> instead of <blockquote class="setlist"> it would be perfect but I could work with the latter.

The problem is I have not been able to find a PHP parser that can do that. Using ParseDown and ParseDownExtra right now, but that does not do the trick.

Does anyone know of a PHP parser that does attributes on blockquotes?