Does not recognise custom html elements

[timoxley]

tldr;

Custom html elements are coming, and marked does not currently recognise them as valid html. Custom elements may have different escaping requirements for their content based on whether the elements contains more elements (like div) or plain text (like script). Perhaps it would be possible to pass which html tags to escape/not escape as configuration properties.

Backstory

I've been experimenting with custom elements and I wanted to inject some into my markdown presentation.

## Shadow DOM is a sub-tree inside a DOM node
#### Like a mini-iframe that replaces an Element.

<h3>Light DOM</h3>

```html
<h3>Light DOM</h3>
`` `
<play-script>
var heading = currentSlide.querySelector('h3')
var root = heading.createShadowRoot()
root.innerHTML = '<a href="#">Shadow DOM</a>'
</play-script>

Source

play-script is essentially a script tag that renders its content, highlighted with highlight.js, and executes only when you click on it.

Problem: currently marked does not recognise tags with hyphens in them as valid html. To get around this quickly, I loosened the html detection regex to also match tags with a single hypen:

Source

-  + '|span|br|wbr|ins|del|img)\\b)\\w+(?!:/|@)\\b';
+  + '|span|br|wbr|ins|del|img)\\b)[\\w-]+(?!:/|@)\\b';

This successfully recognised my custom tag play-script as html, but it raised a new issue:

My custom tag's content was text as opposed to more xml tags, so marked would html-escape all of my script contents. This was no good since I wanted that text to remain as executable script (perhaps I should have looked at unescaping).

So as a hack to make it work, I reluctantly added my specific tag, (and the template tag) as special-cased to avoid escaping, along with style, pre and script:

-        pre: cap[1] === 'pre' || cap[1] === 'script' || cap[1] === 'style',
+        pre: cap[1] === 'pre' || cap[1] === 'script' || cap[1] === 'style' || cap[1] === 'play-script' || cap[1] === 'template',

Source

Special-casing my custom element is clearly not at all a solution, but perhaps the tags that are matched here could be passed in as configuration properties.

[martypdx]

+1

[mikomatic]

+1

[bsr203]

+1

[lkiarest]

+1

[joshbruce]

See #956

FF was a hold out on implementing this until the spec stabilized. Working on cleaning house, thank you for the PR.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements

[joshbruce]

#985