So what fenced containers could we possibly adopt? Say these?
``` python filename ```
...code...
```````````````````````
::: warning custom containers :::
...content...
:::::::::::::::::::::::::::::::::
^^^ spoiler hidden container ^^^
...snape dies...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And if we take the logic these defines the fallback states of generic extensions/web-components, and that the trigger character is ! . (And adopt the consistent attribute syntax) Then:
``` !dot UML Diagram ``` #id .class {key=value}
...UML dot syntax...
```````````````````````
:::::: !gallery cat pics :::: #id .class {key=value}
...commonmark content...
:::::::::::::::::::::::::::::
^^^ !pgp My Pub Key ^^^ #id .class {key=value}
...pgp key here...
^^^^^^^^^^^^^^^^^^^^^^^
Purpose
Think of these, as best practices for preprocessors to avoid colliding with other preprocessors due to syntax collision.
Standardizing the extension metadata in infotext (characters right after ```), will also serve to make it easier for viewers to know what settings is being passed to the plugin/extension/preprocessor, without having to read the extensions instructions.
Also if there is no handler, having a known way for commonmark to handle unknown content will aid in portability, and futureproofing. Especially if we treat the info text after the trigger word as alt definitions, which would be good for disabled users as well.
To aid in this, we could include libraries that people can include in their C, python, etc⌠to safely handle these fenced syntax, and extract these extra metadata in the infotext.
In practice:
code mode
```mermaid
graph TD;
A-->B;
A-->D;
B-->C;
D-->C;
```
acts as normal like:
graph TD;
A-->B;
A-->D;
B-->C;
D-->C;
render mode
```!mermaid
graph TD;
A-->B;
A-->D;
B-->C;
D-->C;
```
may render like:
else fallback to
graph TD;
A-->B;
A-->D;
B-->C;
D-->C;
web components AST intercept
With the above examples if a web component handler exist and we want to render it as one then it make look like:
<dot id=id class=class key=value alt="UML Diagram" > ...UML dot syntax... </dot>
<gallery id=id class=class key=value alt="cat pics"> ...commonmark content... </gallery>
<pgp id=id class=class key=value alt="My Pub Key"> ...pgp key here... </pgp>
How does generic directives factor into this? Well it can intercept the AST before it falls back into web components.
How does fenced containers above factor in? Well if no web-component handler is available, then you can default to either displaying as code (for code blocks), content (for custom containers) or as hidden (using the spoiler box).
Reference:
- Generic directives/plugins syntax
- What could a "spoiler tag" extension look like?
- Block Directives
- Consistent attribute syntax
The minimal option
``` !triggerName info text
...content here...
```````````````````````
If we are seeking the most minimal option. We could just set the best practice as the ! in front of a trigger word like !triggerName, and that the setting is the characters just after the trigger word (which is most likely going to be used as settings). You lose the ability to have alt text to be displayed as a fallback behaviour, since it would be filled with settings gibberish, rather than Diagram of a Cat discription. Also you lose the ability to style the fenced code/content/spoiler fallback behaviour.
and just try your explanation of the difference between â