New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[discussion] markdown-js #3

bpierre opened this Issue Feb 20, 2013 · 3 comments


None yet
3 participants

bpierre commented Feb 20, 2013

I just started to add the testsuite to a markdown-js fork, but I don’t know yet if the author will be interested. Anyway, I think it could be useful for the markdown-testsuite.

markdown-js is supporting multiple dialects, I chose the default one, “Gruber”, which targets the Gruber documentation, like the specification.

Good news: markdown-js already passes 51 of the 102 tests [1]! Most of the failing tests I observed are related to spaces, line breaks, or attributes order.

I posted all the results here (found is markdown-js, wanted is the markdown-testsuite):

Do you think there are things to fix in the suite, based on these results?

What do you think about integrating the testsuite into the popular markdown parsers? It could be a great way to push the Makdown Specification project while improving the interoperability among the existing tools, but maybe it’s too soon?

[1] Instructions to launch the testsuite with markdown-js:

$ git clone && cd markdown-js
$ git checkout -b markdown-testsuite origin/markdown-testsuite
$ git submodule update --init
$ npm install --dev
$ node test/markdown-testsuite.t.js

This comment has been minimized.


karlcow commented Feb 20, 2013

hmmm. So that's the tricky part. When doing the test suite depending on how we output the html there will be layout differences. One way to deal with that would be to have a canonical representation. For example we could decide that

  • any spaces, return characters etc are not relevant for comparing the output (except for pre)
  • character case is not relevant either
  • that there is one serialization for all characters as utf-8 and not necessary their decimal representation.

There must be others. I guess I can't really decide that. The implementers of the different libraries could decide. The important is that it is syntactically correct.

Some libraries are also generating things like automatic id for the headers. Should it be fixed or just ignored when testing.


This comment has been minimized.


cirosantilli commented Apr 22, 2014

@karlcow I propose this issue be closed.

  • the normalization question is isolated at #5, with possible fix at #31
  • the integration with multiple engines has already been started, and the most important engines have likely already been added

This comment has been minimized.


karlcow commented Apr 25, 2014

closing this issue. Thanks @cirosantilli for all the work so far.

@karlcow karlcow closed this Apr 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment