Roadmap for CommonMark

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.

2 Likes

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.

About URL parse. For JS we started working on https://github.com/markdown-it/mdurl, that can save your time.

Can you link to the relevant topics here? I don’t know what this means without examples.

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, because those are focused on practical aspects of parser use. Except assorted OSS projects, feedback is collected from npm registry team and disapora team.

Unclear. It looks like by HTML block termination you are referring to this?

<!-- one-liner -->

<!-- two-liner 

-->

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)?

See examples below.

Empty line trash everything till end of file:

<!-- two-liner 
indented

block comment
-->

Indent will cause rendering block comment as code block:

        <!-- two-liner 
        indented

        block comment
        -->

Similar problem can be on practice with script/style tags. That’s all mentioned in different messages of Raw HTML blocks proposals -- comments wanted

scrit/style are less critical, but comments worth to be improved.

1 Like

+++ 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.

1 Like

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 from CommonMark.

@Knagis, there’s this list of issues to resolve before 1.0 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.

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.

2 Likes

IMHO, inability to extend syntax is much more serious problem. People don’t leave CommonMark, they leave reference implementation.

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 …).

1 Like

See

and

1 Like