Support wrapping Markdown with div tags

[kaushalmodi]

Hello,

By default we can wrap Markdown code with inline tags.. so <span class="foo">_italics_</span> will render the internal Markdown.

But it does not work when wrapped with <div>, and that's a major limitation! That disallows us from setting specific classes for Markdown tables, etc.

The good thing is that div wrapping is allowed in CommonMark spec: https://github.com/russross/blackfriday/issues/404#issuecomment-341551330

As per http://spec.commonmark.org/0.18/#example-108, this is a valid way of div-wrapping Markdown text that should be rendered:

<div>

*Emphasized text*

</div>

The newlines after <div> and before </div> are needed.

Is this something that could be added?

This sort of works with Blackfriday but because of an undocumented ugly hack.. example.. it would be nice to get rid of those empty divs in the hack.

Many thanks.

[kjk]

Please provide a full example:

• markdown text
• what is currently being rendered
• what do you expect to be rendered

That being said, I looked into CommonMark compatibility and it would be so much work that it falls outside of this project's ambitions.

Making other substantial changes to the parser could also be outside of scope.

[kaushalmodi]

Markdown text

<div class="bar">

**Hello**

- Should work as per CommonMark

</div>

Current output

<div class="bar">

**Hello**

- Should work as per CommonMark

</div>

Expected output

<div class="bar">
    <strong>Hello</strong>
    <ul>
        <li>Should work as per CommonMark</li>
    </ul>
</div>

---

That being said, I looked into CommonMark compatibility and it would be so much work that it falls outside of this project's ambitions.

My feature request is for this small part of CommonMark spec and not the full spec compatibility, as this will allow all the Markdown blocks to be wrapped with div classes.

[kaushalmodi]

OK, my proposal is different from the CommonMark spec in one crucial aspect.. While the CommonMark spec wraps the rendered Markdown HTML in <p> tags, I propose to not do that.. because the Markdown could also be a table.. and I'd like that table to be wrapped only in <div> tags; you cannot wrap tables in <p> tags.

[MichaelMure]

As another data point, this is a somewhat common pattern to center align things in a readme on github (badges in particular).

An example:

<div align="center">

[![Build Status](https://travis-ci.org/MichaelMure/git-bug.svg?branch=master)](https://travis-ci.org/MichaelMure/git-bug)
[![Backers on Open Collective](https://opencollective.com/git-bug/backers/badge.svg)](#backers) [![Sponsors on Open Collective](https://opencollective.com/git-bug/sponsors/badge.svg)](#sponsors) [![License: GPL v3](https://img.shields.io/badge/License-GPLv3+-blue.svg)](http://www.gnu.org/licenses/gpl-3.0)
[![GoDoc](https://godoc.org/github.com/MichaelMure/git-bug?status.svg)](https://godoc.org/github.com/MichaelMure/git-bug)
[![Go Report Card](https://goreportcard.com/badge/github.com/MichaelMure/git-bug)](https://goreportcard.com/report/github.com/MichaelMure/git-bug)
[![Gitter chat](https://badges.gitter.im/gitterHQ/gitter.png)](https://gitter.im/the-git-bug/Lobby)

</div>

[sbeliakou]

The same here: https://play.golang.org/p/Th2EDlOGmSX

[sbeliakou]

As a work around: https://play.golang.org/p/caH-GSovGRZ

<div>
![Doesn't work](https://image01_9.png)
</div>

<div>
![Works](https://image01_9.png)
</div><!-- dummy -->

[sbeliakou]

This ugly stuff works for me: https://play.golang.org/p/JTE8bVfhXXv

[copernico]

Pandoc allows something like this:

:::{#my_id .someclass .someotherclass}
text
:::

which becomes something like:

<div id="my_id" class="someclass someotherclass">
text
</div>

One can argue if the triple colons (:::) are the most elegant syntax for this, but the solution is very neat and useful anyway, I would love to see it in gomarkdown.

[kjk]

To set the expectations: probably won't happen as it most likely would require a big change to the parser. Currently those 2 <div> are separate HTMLSpan ast nodes, with other ast nodes in between.

We would probably need to add HTMLBlockStart and HTMLBlockEnd nodes, recognize this pattern in the parser, change the renderer.

If anyone wants to give it a go, I'll look at the PR but I'm unlikely to work on such big (?) change.

[copernico]

Hi @kjk , thanks for taking the time to consider this idea and to assess its feasibility, too bad it's so difficult to implement...