avoid wrapping custom elements in `<p>` tags

[thescientist13]

It looks like the output in all markdown is always wrapped in a <p> tag.

<h2>11ty + WCC Demo</h2>
<p><x-greeting>
      <template shadowroot="open">
        
  <p>Hello from the greeting component!</p>

      </template>
    </x-greeting></p>

Or with innerHTML it breaks apart even more. 🤔

Had this same issue with Greenwood and so would like to see if there is a proper way to avoid this.

[KaiPrince]

I'd like to take a shot at tackling this one. Could you provide a test case to reproduce the error?

[thescientist13]

Yeah, I have this little repo setup that could be a good starting point. I think the reproduction would just be using a custom element tag in markdown

<my-component></my-component>

FWIW, this seems to be a general issue with markdown (and custom elements?), and something I've documented here a bit more in depth (amongst some other issues) so figuring this out would be great for Greenwood too!

You can see how Greenwood works around this currently in its markdown plugin, but ideally would like to figure out if it's something I'm doing wrong with markdown?

---

FWIW, things are a little outdated here in this repo, so just a heads up there. Some general dependency updates (like WCC) would probably be in order.

[KaiPrince]

Looks like this is caused by the markdown spec having a pre-defined list of all "block level" tags. Everything else is considered inline and gets wrapped by a paragraph.

address, article, aside, base, basefont, blockquote, body, caption, center, col, colgroup, dd, details, dialog, dir, div, dl, dt, fieldset, figcaption, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hr, html, iframe, legend, li, link, main, menu, menuitem, nav, noframes, ol, optgroup, option, p, param, search, section, summary, table, tbody, td, tfoot, th, thead, title, tr, track, ul

https://spec.commonmark.org/0.31.2/#html-blocks

We have some options:

1. Don't fix. Spec is working as intended. Users can wrap in <div> if they want it to be block level.
2. Wrap in <div> ourselves using a pre-process transform
3. Strip the <p> using a post-process transform
4. Add the known custom element tags to the list of block elements by adding an html_block rule to markdown-it https://markdown-it.github.io/markdown-it/#Ruler.before. Assuming they're using the default library.

I'm in favour of 1 or 3.

[thescientist13]

Ah, interesting findings.

I found these relevant WICG threads that do indeed confirm / affirm that custom elements are treated as display: inline by default, which I guess would explain the treatment by markdown parsers

• [Custom Elements]: Custom elements should be display: block by default WICG/webcomponents#224
• Should shadow host have display: block by default? WICG/webcomponents#426

I would prefer to go with option 3 as you recommend, as it's the same workaround we do in Greenwood right now and seems to be working well so far and would likely "just work" as a user would expect, when compared to having to having to add a wrapping <div> which is pretty subtle and easy to overlook. The wrapping <p> tags is pretty annoying and certainly not what I would have expected from a markdown parser, e.g. just leave what I wrote alone; it's not markdown content so just don't touch it, lol 😅

Option 4 sounds nice, but then presumably a user would have to be constantly updating a config with all the custom element tag names they are using, I guess.