remark-custom-blocks nested sections and custom properties

[aiwatko]

I'm trying to attempt these two things with no success fo far:

1. Nested sections:
   i.e.
   [[section]]
   | # title
   | [[nestedSection]]

2. Properties passed to the section:
   i.e.
   [[section bgColor="blue" width="1024"]]
   which would result in:

section: {
  classes: 'section',
  bgColor: 'blue',
  width: '1024'
}

This approach would allow more flexibility with section, i.e. there would be just one section instead of creating:

sectionBgBlue: {
  classes: 'sectionBgBlue'
}.
sectionWidthDesktop: {
  classes: 'sectionWidthDesktop'
}

Is any of those possible? Thanks in advance!

[artragis]

For your first question, I manage to get a proper result with :

[[q]]
| # title
| [[q]]
| | bla

the html is

<div class="custom-block custom-block-question">
    <div class="custom-block-body">
        <h3 id="title">title<a aria-hidden="true" href="#title"><span class="icon icon-link"></span></a></h3>
        <div class="custom-block custom-block-question">
            <div class="custom-block-body"><p>bla</p></div>
        </div>
    </div>
</div>

Here I used "q", to perform that, we configured the plugin like this :

{
        q: {
      classes: 'custom-block-question',
      title: 'optional',
       },
}

[aiwatko]

Thanks a lot @artragis, good point. Would you also be able to contribute to my second question?

[artragis]

In fact I don't know. I think it is possible to develop it. @vhf do you agree with that?

We could specify it as :

when we configure the plugin like :

{
   blockName: {
        classes='classes is stil mandatory',
        title: 'optional',
        customStyles: {
            regex: /(?:width=([0-9]+(?:%|px|em|pt));)?(?:\bbgColor=(blue|red|green|orange)?/,
            cssCode: (capture) => {
                const width = capture[1] || '100%'
                const bgColor = capture[2] || 'inherit'
                return `width:${width};background-color:${bgColor}`
           }
     }
}

with this configuration, we can parse

[[blockName]]
| bare block

[[blockName width=50px bgColor=25]]
| block with custome style but without title

[[blockName width=50px | title]]
| block with only width and a title

when styles are provided, it just add a css style="${blocConfig.customStyles.cssCode(capturedStyles))}"

Are you ok with that @vhf ? Or do you think it's not a good thing for remark-custom-blocks?

[vhf]

I think adding this feature is interesting. I'm not sure what would be the best way of configuring this feature though, for instance I think I'd prefer a whitelist approach where we first parse all key/values over the suggested regexp capture.

IIRC @arobase-che developed something similar to this. Could you please show us what you did?

[arobase-che]

Hi ! 😄

Ty @vhf, yes i developed a plugin remark-attr to add custom attributes to markdown elements.

It uses md-attr-parser to parse the common syntax for attributes : attr=value attr2="value" attr3='value' attr4 either with curly braces or not {attr=val}.

The goal of remark-attr is to add attributes syntax after the usual syntax. So the syntax will be :

[[blockName]]
| foo
{attribute1="value"}

That may suits your needs. But i never use it on plugins.

To use a syntax like :

[[blockName width=50px bgColor=25]]
| block with custome style but without title

Since it's a custom plugin, you have to extract the string "width=50px bgColor=25" and feed md-attr-parser with that string. Safer than a regex i think. remark-attr support a black or white list approach, but if you use md-attr-parser, you are on your own.

I hope it helped. In any case, it needs little development, but still development.

[vhf]

Thanks @arobase-che , we'll need to think about it a bit more.

@aiwatko Could you please expand on your needs (2nd point: properties)? How would you want remark-custom-blocks to be configured? Would it only add HTML attributes to the top-level HTML tag for this block?

We don't have a use case for this at the moment and since we use this plugin in a setup where we don't trust the user, we need to make sure it stays secure -- users should not be able to add arbitrary properties/values (think of XSS/CSRF, things like src="javascript:alert('hello')" and much more). I wouldn't mind adding support for what you suggest though, I'd just need more info to make sure it's safe for all use cases, easy to configure, etc.