# Roadmap for CommonMark **URL:** \ **Category:** Spec\ **Created:** [March 2, 2015, 8:20pm UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081 "2015-03-02T20:20:18Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Knagis](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/k/ba9def/32.png) [@Knagis](https://talk.commonmark.org/u/Knagis)\ **Post date:** [March 2, 2015, 8:20pm UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/1 "2015-03-02T20:20:18Z")
Is there a roadmap for the future of CommonMark? Almost all topics that request new features (tables, unicode bullets, attributes etc.) have been deferred with the statement that the specification has to be stabilized before the new features are considered. At this point it would be helpful to have an idea of when that could happen. For example, if the roadmap shows that table syntax will be worked on only in 2016, then an implementation might decide to choose one existing syntax and implement that as an extension even if that implies the risk of having to implement another different syntax once the spec gets there. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [March 3, 2015, 4:27am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/2 "2015-03-03T04:27:05Z")
I’m not sure I can say anything very helpful here. There are still a few tricky things to resolve in core: chiefly raw HTML and backtick fences. I’d also like to get clearer about URL handling and normalization, and whether to use XML for the spec tests. My best guess is that we might get to thinking seriously about extensions this summer. (Summer is also when I have the most time to work on projects like this.) ---
**Author:** ![vitaly](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 3, 2015, 5:18am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/3 "2015-03-03T05:18:37Z")
Thanks for info about summer. A couple of additions: - It could be helpful also to have public defered list of accepted requests, ordered by priorities. At least, users will be able to see if problem was scheduled and what to expect in general. - Mark if some critical bugs can be solved soon. For example, most users don’t care much about backticks, but have pain with current behaviour of html block comments and custom html tag names. - For actively mainained implementations it will be useful to have more regular cummulative spec releases. For example, once a month. About URL parse. For JS we started working on [https://github.com/markdown-it/mdurl](https://github.com/markdown-it/mdurl), that can save your time. ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [March 3, 2015, 7:01am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/4 "2015-03-03T07:01:05Z")
> [@vitaly](#): > > most users don’t care much about backticks, but have pain with current behaviour of html block comments and custom html tag names Can you link to the relevant topics here? I don’t know what this means without examples. ---
**Author:** ![vitaly](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 3, 2015, 7:43am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/5 "2015-03-03T07:43:48Z")
[http://talk.commonmark.org/t/raw-html-blocks-proposals-comments-wanted/983/30?u=vitaly](http://talk.commonmark.org/t/raw-html-blocks-proposals-comments-wanted/983/30?u=vitaly) I’d recommend to study [https://github.com/markdown-it/markdown-it/issues](https://github.com/markdown-it/markdown-it/issues), because those are focused on practical aspects of parser use. Except assorted OSS projects, feedback is collected from npm registry team and disapora team. ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [March 3, 2015, 8:00am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/6 "2015-03-03T08:00:40Z")
Unclear. It looks like by HTML block termination you are referring to [this](https://github.com/markdown-it/markdown-it/issues/51)? ``` ``` I clicked on every item in that list and I still don’t understand what you mean by > users… have pain with … custom html tag names Can you provide a simple example, as I requested (and as I extracted, above)? ---
**Author:** ![vitaly](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 3, 2015, 9:14am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/7 "2015-03-03T09:14:30Z")
See examples below. Empty line trash everything till end of file: ```auto ``` Indent will cause rendering block comment as code block: ```auto ``` Similar problem can be on practice with script/style tags. That’s all mentioned in different messages of [Raw HTML blocks proposals -- comments wanted](http://talk.commonmark.org/t/raw-html-blocks-proposals-comments-wanted/983) scrit/style are less critical, but comments worth to be improved. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [March 3, 2015, 6:57pm UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/8 "2015-03-03T18:57:33Z")
+++ vitaly [Mar 03 15 05:28]: > - Mark if some critical bugs can be solved soon. For example, most users don’t care much about backticks, but have pain with current behaviour of html block comments and custom html tag names. Yes, HTML revisions are a top priority; I’m in a busy period but should get to them before too long. > - For actively mainained implementations it will be useful to have more regular cummulative spec releases. For example, once a month. Yes, can do. ---
**Author:** ![Knagis](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/k/ba9def/32.png) [@Knagis](https://talk.commonmark.org/u/Knagis)\ **Post date:** [October 25, 2015, 9:49am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/9 "2015-10-25T09:49:59Z")
Maybe we could resurrect the idea of a roadmap? The one most commonly requested feature seems to be tables - in fact the lack of them has been the reason why some have [migrated away](https://github.com/madskristensen/WebEssentials2015/commit/62e792d9e419a16a85f8c06c9c165d8c57aa6c72) from CommonMark. ---
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [October 25, 2015, 11:03am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/10 "2015-10-25T11:03:10Z")
@Knagis, there’s [this list of issues to resolve before 1.0](http://talk.commonmark.org/t/issues-to-resolve-before-1-0-release/1287) which could be considered a roadmap. It does not include a timeline though. There could be more indication as to the extension syntax that will eventually be adopted though. That way app developers can implement something now even if the precise details change later. Table syntax is a good example. There are current many different syntax variations to choose from. CommonMark could have a stance on this now, even if the core has yet to be finalised. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [October 27, 2015, 8:43pm UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/11 "2015-10-27T20:43:32Z")
Yes, that’s the best place to look for a roadmap. I’m sorry progress has been slow – my day job has not left me much time. I expect to have more time to work on this in December. ---
**Author:** ![vitaly](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [October 30, 2015, 6:02pm UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/12 "2015-10-30T18:02:13Z")
> [@Knagis](#): > > The one most commonly requested feature seems to be tables - in fact the lack of them has been the reason why some have migrated away from CommonMark. IMHO, inability to extend syntax is much more serious problem. People don’t leave CommonMark, they leave reference implementation. ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 1, 2015, 9:27am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/13 "2015-11-01T09:27:37Z")
IMO, the “syntax extension problem” can be solved without (much) change to the reference implementation, and in a [very general way](http://www.tin-pot.net/Mark-Up_Chain.html). But I would consider the ability to write some kind of tables in _native CommonMark_ important enough to add it to the spec and the reference implementation—until this happens, you’re right that “extended syntax” is one work-around, writing HTML tables in the _CommonMark_ script is another (albeit an **ugly** one …). ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [March 17, 2017, 12:21am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/14 "2017-03-17T00:21:51Z")
See > [@Issues we SHOULD resolve before 1.0 release](https://talk.commonmark.org/t/issues-we-should-resolve-before-1-0-release/2136): > > This is a companion topic for [the CommonMark 1.0 release](https://talk.commonmark.org/t/issues-to-resolve-before-1-0-release-8-12-remaining/1287). These are issues that SHOULD be resolved before the 1.0 release, if possible, but are not required to release CommonMark 1.0. Turn empty link definitions into anchors? (SHOULD) Example: [link text]: The link text cannot contain links, though it may contain images. Etc. ... later ... See the discussion of [link text], above. [Issue](https://github.com/jgm/CommonMark/issues/172) and [discussion](http://talk.commonmark.org/t/turning-empty-link-definitions-into-anchors/893). Email addresses regex (SHOULD) There are some [tests](https://github.com/michelf/mdtest/blob/master/PHP%20Markdown.mdtest/Email%20auto%20links.text) that our current parsers fail. … and > [@Issues we MUST resolve before 1.0 release \[6 remaining\]](https://talk.commonmark.org/t/issues-we-must-resolve-before-1-0-release-8-remaining/1287): > > Here are some issues in the spec that must be resolved before a 1.0 release. To keep us focused, the optional [should resolve issues are in this topic](https://talk.commonmark.org/t/issues-that-should-be-resolved-before-1-0-release/2136) and [successfully resolved issues are in this topic](https://talk.commonmark.org/t/issues-resolved-for-the-1-0-release/2137). To keep things organized, please comment in the linked discussions or issues, not here. If there’s no linked discussion, start a new one on this forum. I will edit this as things are resolved or new issues come up. Code blocks and spans Backtick fences and inline code collision There’s an am… ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [March 17, 2017, 12:21am UTC](https://talk.commonmark.org/t/roadmap-for-commonmark/1081/15 "2017-03-17T00:21:57Z")