Skip to content
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

Select a js implementation as the standard #4

Open
devinrhode2 opened this issue Sep 18, 2013 · 8 comments
Open

Select a js implementation as the standard #4

devinrhode2 opened this issue Sep 18, 2013 · 8 comments

Comments

@devinrhode2
Copy link

The biggest users of markdown really just need a js implementation (StackExchange, GH, Meteor)

Standardizing on a js implementation means less spec work and we will have an official spec sooner.

@devinrhode2
Copy link
Author

To be clear, the idea here is to simply let some js implementation be the standard.

@devinrhode2
Copy link
Author

There could still be a separate spec repo which contains tests, which would then be a submodule for the standard js implementation.

@forivall
Copy link

Are you taking inspiration from Python's model of having a reference implementation? If so, then 👍

@devinrhode2
Copy link
Author

Actually, OAuth (Google "fuck oauth")
On Sep 24, 2013 11:39 AM, "Jordan Klassen" notifications@github.com wrote:

Are you taking inspiration from Python's model of having a reference
implementation? If so, then [image: 👍]


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-25031132
.

@styfle
Copy link

styfle commented Sep 25, 2013

I would vote for GFM since it adds the language definitions for code blocks (Fenced Blocks) so you can add syntax highlighting where appropriate. GFM also implements Task Lists is one of the biggest reasons to write plain text: keeping track of a TODO list.

EDIT: I realized GFM is actually the spec and not the implementation so maybe something like marked

@mrft
Copy link

mrft commented Jul 2, 2014

GFM has a few nice extensions, but it's a pity that no one seems to be using dokuwiki syntax instead of markdown.

What looks more intuitive to you:

Mardown's:

_italic_ or *italic* 
__bold__ or **bold**

or dokuwiki's

**bold**, //italic//, __underlined__

(add GFM's strikethrough syntax to that and you have all you need)

--mistake--

(of course there's more to dokuwiki's syntax, like tables etc. probably very similar to GFM's tables)

@brunobord
Copy link

@mrft sorry, but mentionning dokuwiki syntax in a markdown-centric discussion reminds me of: http://xkcd.com/927/ ;o)

@mrft
Copy link

mrft commented Jul 11, 2014

You have a point, if you consider markdown as being something completely different from dokuwiki's syntax, but actually you could consider all these plaintext-formats-translated-to-formatted-text as being the same thing, just with some syntax variations (which is exactly why people are preferring one implementation over the other, because there is no real standard).

To me there is no fundamental difference between GFM or dokuwiki syntax, they are just variations (and actually GFM added some extras to markdown that are very similar to things that have existed for many years in the dokuwiki syntax).

So me mentioning dokuwiki is not so different from someone else pointing out he likes GFM better.

If you want to establish a 'standard', you might as well try to make some changes for the better while at it.

Besides, marked is an implementation, but you can set a lot of options to either support syntax X or syntax Y, so what would it mean if you would 'choose marked as the reference implementation'? You'd have to specify which options are enabled.

So, if someone else would have mentioned this, I would still have considered it useful input... because choosing an implementation as a reference will be mostly about syntactic preferences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants