A new web component is needed to translate markdown into html sanitized

[UcDust]

We use the marked npm package in the brands site to display class documentation. We need something similar in RP, to allow custom formatted markdown to be used to output people data. We could use another package like DOMPurify to sanitize the text.

<ucdlib-md ignore="H*"> - Means don't render it exclude="img" - Means excise it from the output subset?="core|full|parsimonious" - Specifies some common sets of ignores/excludes, that we use

The docs show the ability to override a list of renderer functions which would override the default renderer. We could use these to ignore specific tags if specified in the element attributes. From the docs-

const renderer = { heading(text, level) { return something; } };

Then marked.use({ renderer }); with our list of overridden render functions. In our case, we would return an empty string or perhaps the default text, depending on the element attributes.

We can override these functions:
Block-level renderer methods

code(string code, string infostring, boolean escaped)
blockquote(string quote)
html(string html)
heading(string text, number level, string raw, Slugger slugger)
hr()
list(string body, boolean ordered, number start)
listitem(string text, boolean task, boolean checked)
checkbox(boolean checked)
paragraph(string text)
table(string header, string body)
tablerow(string content)
tablecell(string content, object flags)

Inline-level renderer methods

strong(string text)
em(string text)
codespan(string code)
br()
del(string text)
link(string href, string title, string text)
image(string href, string title, string text)
text(string text)

These elements shadowDOM styling needs to match the patternLabs styling.

[qjhart]

@UcDust Looks pretty good to me. My thinking is that we can have a few default renderers that have our overridden functions for various types. Can you be thinking of how we can be showing examples of different MD renders?

[jrmerz]

IMHO, if you want flexible client side markdown rendering, just use the NPM packages. ie:

document.querySelector('#md-rendered').innerHTML = sanitize(mdRenderer(mdText));

I would suggest the advantages of a custom element, that we put time into supporting, would be that there is an opinion layer. So we are saying; this is our renderer, this is our sanitize utility, this is our standard setup. Of course you can allow for a couple optional params. The question I would have, is that even helpful? Perhaps a little. Our standard setup with single npm install command.

If we are going to implement a markdown element, the rendered markdown should be in the local dom. So if you have <ucdlib-md id="md"></ucdlib-md> and did something like document.querySelector("md").data = mdTxt then the markdown HTML would render into the local dom. Or if you wanted to declaratively set the markdown you could do something like:

<ucdlib-md id="md">
  <span class="md">raw markdown goes here</span>
</ucdlib-md>

And then the element hides the raw and inserts a new rendered tag as child element.

You could also look to do something like:

<ucdlib-md id="md">
  raw markdown goes here
</ucdlib-md>

Completely replacing the raw markdown with the rendered, however it doesn't provide a nice update cycle. ie it's rendered and done.

[qjhart]

Doesn't the document.quewrySelector solution suffer from the same update problems? I guess one thing I think is nice is that the custom elements are more declarative, you add it in and it works.
Does it make sense to think about the old polymer "everything is an element" and have an engine-like thing:
<ucdlib-md-renderer render-class="md-rendered" subset="parsimonious"> which then sort of does what you suggested?

I guess markdown can get really messy anyways but is it better to use a tag and avoid things like <li class="md-rendered">