# Guide for syntax extensions **URL:** \ **Category:** Spec\ **Created:** [September 4, 2014, 1:57am UTC](https://talk.commonmark.org/t/guide-for-syntax-extensions/193 "2014-09-04T01:57:25Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![jroper](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jroper/32/114_2.png) [@jroper](https://talk.commonmark.org/u/jroper)\ **Post date:** [September 4, 2014, 1:57am UTC](https://talk.commonmark.org/t/guide-for-syntax-extensions/193/1 "2014-09-04T01:57:25Z")
There are many markdown extensions out there. I’m wondering if it’s worth, as an appendix to the spec, for the authors of the spec to write a guide for choosing the syntax of extensions. This section could capture things that aren’t in the spec like: - Characters and/or constructs that should be considered reserved for a possible future addition to this spec - Thoughts by the authors on what sort of syntax could be used to introduce new inline or block features - Patterns for syntax extensions For example, let’s say someone wants to implement an extension that renders a table of contents. Would something like @toc@, or %toc%, work as a block element? Or is that likely to conflict with other known extensions or possible future additions to the spec? Another example is an extension we use for the [Play Framework documentation](https://github.com/playframework/play-doc) that pulls in code snippets from external files (so that the code snippets can be compiled/run/tested), it’s a block element similar to the image syntax: ``` @[snippetlabel](path/to/code.scala) ``` This is a possible pattern that could be repeated for many different types of extensions that refer to external resources, and if the authors of the spec think this is a good pattern, of prefixing a link with a special character like this, then perhaps it’s worth mentioning it. --- _[View the full topic](https://talk.commonmark.org/t/guide-for-syntax-extensions/193)._