Fenced block but not fenced code block

[Jerry]

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.

[zzzzBov]

@Jerry

we often would like to use an inset with a quote

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:

Consistent attribute syntax

Eventually, the spec should specify a consistent way to add attributes to at least the following elements: headers, images, code blocks (and maybe even tables, block quotes and inline code and quotes). The most important attributes are certainly id (to enable links to those elements) and class (for styling) which might have shortcuts like #myId and .myClass but other attributes (like width and height for images) are useful as well. Stmd currently specifies info strings for code blocks. I think …

---

This one covers a generic block syntax

Block Directives

A block directive allows for embedding or calling certain operations that does not require extending the core syntax. (Note: There is a debate between ! vs @ as generic directive indicator. I prefer ! as it indicates embedded content or intent.) Block Syntax Block syntax, using repeated sequence as delineators. !!! & the code fence syntax is used to indicate if content should be treated as normal text or code blocks if no extension found. (Could also indicate to extension on the type of fencin…

---

This one covers generic plugins

Generic directives/plugins syntax

This is a proposal for a generic syntax to accommodate custom directives/plugins, which is as simple and markdown-like as possible while still accommodating a lot of use cases. While not enabling all markdown extensions (e.g. tables, custom linebreak behaviour etc. doesn’t really fit the template), it works for a lot of them. There are three different kinds of directives: Inline, start with one colon (analogous to spans) Leaf block, start with two colons (analogous to empty divs) Containe…

---

This one covers <aside>

Pipe character (|) for <aside>

I was writing a blog post in markdown and I wanted to use an <aside> element for a note within the post. <blockquote> is often (mis)used for such things, which makes sense because writing: > **Note:** lorem ipsum is quite straightforward and commonly renders into some nicely boxed content. However, since the content is not a quote and the HTML5 spec says: Content inside a blockquote other than citations and in-line changes must be quoted from another source this becomes problematic. I thi…

---

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.

[Jerry]

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!

[Crissov]

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

[Jerry]

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?