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.
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.)
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.
I’d recommend to study 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.
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.
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.
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.
IMO, the “syntax extension problem” can be solved without (much) change to the reference implementation, and in a very general way.
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 …).