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

Closed
bpierre opened this Issue Feb 20, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@bpierre

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): https://gist.github.com/bpierre/4991393

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 https://github.com/bpierre/markdown-js && cd markdown-js
$ git checkout -b markdown-testsuite origin/markdown-testsuite
$ git submodule update --init
$ npm install --dev
$ node test/markdown-testsuite.t.js
@karlcow

This comment has been minimized.

Owner

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.

@cirosantilli

This comment has been minimized.

Contributor

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
@karlcow

This comment has been minimized.

Owner

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