Related to the discussions here: Generic directives/plugins syntax, here: Guide for syntax extensions and here: Add “plugin” syntax to the spec, but from a different perspective, I propose that the CommonMark specification include optional elements.
I don’t mean optional elements with special namespaces I mean optional elements that are completely generic in terms of syntax like the rest of the spec, but optional. At least the following would have to be considered:
- What would be the process for getting optional elements accepted into the spec?
- How would the spec convey that an element is optional?
- How could this be done in a way that doesn’t adversely affect the deterministic nature of implementations of the spec?
For a made up example consider two imaginary optional elements that both render text small:
- surround text with $$: $$small text$$
- surround text with $$$: $$$small text$$$
If both of these optional elements were implemented by a markdown rendering engine, would they render as something like small text or $small text$? It depends which is considered to take priority and this should be handled cleanly by the spec for example by assigning each optional syntax a sequence which is the order of processing.
Namespacing and plugins can then be used to handle esoteric or ‘uncommon’ extensions and ‘optional syntax’ can cover the things like table and footnotes syntax where competing implementations exist.
This opens the door to including syntax that is hard to parse or maintain (like some proposed table syntax) as supporting the syntax is then optional for each implementation.