Markdown implementation

[daGrevis]

Are there any plans for Markdown implementation?

This is how I see it:

There are two options:

1. Plain Markdown,
2. Parsed Markdown that's just HTML (there are few Markdown parsers in JavaScript already);

If user clicks, lets say, "bold" button when it's option #1 -- selected text is wrapped in "**". If he clicks the same button when #2 option is selected, then the same happens, plus, new text is parsed and displayed.

Are there any plans for it? Maybe to create plugin that do it?

[orefalo]

+10 that would be nice indeed

[html5cat]

Agreed, there's a surprising lack for good Markdown editing tools.
Not sure when, but this will definitely happen.
Thanks for the suggestions!

[orefalo]

I remember a project on github that provided a set of rules to convert the typical html output of editor such as redactor into markdown. will try to find it

got it -> https://github.com/leeoniya/reMarked.js

not sure if it's the right way to go...

[html5cat]

Thanks @orefalo, that would be handy!

[treefitty]

I'd also love to see this integrated as it's the only thing stopping us from using this impressive project

[tehnorm]

+1 for this - an awesome markdown based editor would be tops!

[vjpr]

+1

[daGrevis]

Well, anyone wants to contribute or wut? Lets write down initial requirements and start work, shall we? :)

[ShawnMcCool]

+1

[alexkravets]

+1

[Madd]

+1

[marcusgreenwood]

+1

[mattstein]

+1

[hadees]

+1

[leeoniya]

reMarked.js author here. i've got a hack night coming up next week. might take a stab at integration. in fact, this was the exact purpose for writing that lib, see the readme! redactor looks like a great fit for it too, being a clean, minimal editor.

just to be clear, this is a one-way thing like "generate markdown" or "show markdown source". you cannot then edit that markdown and expect changes back in the editor. the markdown format throws away too much info to faithfully recreate the original html just from the generated text, no matter how good a markdown parser you use.

[daGrevis]

That' just not fun... button to switch from-to Markdown is not awesome at all.

[ShawnMcCool]

My goal would be to have a visual editor that a client can use that outputs to markdown for my system. Not something that requires people to know basic markdown tags and then be able to preview it. We already have that.

[leeoniya]

@daGrevis what you're asking for is called a WYSIWY_M_, not a WYSIWY_G_ editor. there are plenty that already exist for markdown.

http://pushingkarma.com/projects/jquery-wysiwym/
http://mouapp.com/

and others...

http://joncom.be/experiments/markdown-editor/edit/
http://dillinger.io/
http://markdownpad.com/
http://markable.in/editor/
https://github.com/adam-p/markdown-here
http://codemirror.net/mode/gfm/index.html

these editors have 3 purposes

1. for people who already know and write markdown with keyboard only
2. people learning markdown who need to use mouse and click buttons
3. when a better representation is not available

in a browser, it is truly and utterly pointless to make an editor that has html buttons for manipulating markdown text. why?! you have html available! which is a far cleaner and more readable format. not only that, but you already have a full visual editor for it that you're working in. the whole point of markdown is either to write without taking your hands off the keyboard and reducing keystrokes (compared to html) and/or to create a still-readable text-only presentations for storage or plain text email.

if you want this interactivity feature added just because it's "fun" and "awesome", you may have to do it yourself.

IMHO

[leeoniya]

@ShawnMcCool that's exactly the point.

[hadees]

I understand there are technical challenges but what I really want is something where the power users could switch to markdown in the editor and make changes then switch back. I just think markdown is nicer to use then a WYSIWYG but I know that, at least on my site, there will be a lot of users who just won't get it which is why I need a default WYSIWYG editor.

[daGrevis]

The way I see it...

You type in "bold", but you don't see "bold" — you see bold.

There is no "preview", because preview is instant. The source of it is still in Markdown.

I know it's a technical challenge, but I think it's worth the trouble.

P.S. I'm sorry I hurt you, but I really think that if we do yet-another-markdown-editor, it really need to differ; it need to be awesome!

[marcusgreenwood]

Agreed. It's effectively markdown as you type but parsed as WYSIWYG as soon as it matches or at some event (e.g. you get to line ending). Working out when to convert from markdown to WYSIWYG is probably the trickiest part to the challenge but I'm sure it could be done! 👍

[marcusgreenwood]

Or perhaps some kind of "auto-complete" like this Github textarea has when you enter ":" so that you can explicitly select one of the markdown styles.

[hadees]

I think something that just automatically parsed everything you typed looking for markdown could be kind of error prone. What if an unsuspecting user actually wanted to type bold. I think just being able to switch back and forth would be easier to use. There are WYSIWYG editors that do this with html right now. But doing it in markdown you don't have to be as worried about users screwing up your site with bad html.

[daGrevis]

Nop, because there isn't such thing as "bad Markdown". Everything is Markdown and Markdown can't break anything; worse thing that can happen is that it does not compile to HTML. Markdown is always valid.

So you have written "bold, but then you don't want it to be bold anymore. You just press delete until cursor is right past bold and w/ next keypress it goes back to plain text and looks like "*bold".

About auto-complete... I don't see it as must-have feature — first I would like to see that text gets shown as HTML instantly.

[ShawnMcCool]

For me, markdown is a much cleaner format that I can render to any HTML that I'd like. It is hard to programatically change the formatting of HTML.

[leeoniya]

the fastest path to a syntax-styled editor would probably be to convert the html to markdown via reMarked.js, then dump the result into CodeMirror3 or rover-editor which will overlay on top of redactor. when switching back, use a full markdown > html converter like marked.js or markdown-js and dump the result back into redactor.

to save a lot of weight, you could ditch the full md > html converters (which implement their own markdown parsers also) and spend some more time to hook into codemirror's already-parsed internal markdown representation and make an HTML renderer for that lexed tree using some visitor pattern.

you would have to restrict redactor to some markdown-mode subset of features, avoiding some html,css,redactor stuff that cannot be translated back and forth and would be lost. eg: color, alignment, positioning, videos. i imagine that uniform indentation can be preserved by adding some code to recognize it in the markdown and adding the necessary css back via margin-left, as redactor currently handles this.

hookable markdown parsers/converters

• https://github.com/chjj/marked
• https://github.com/evilstreak/markdown-js

syntax-colored code editors for markdown

• http://codemirror.net/mode/gfm/index.html
• https://github.com/kasparsd/rover-editor

i think doing anything else would just be wasteful, complicated (and inferior) re-invention of the wheel. you could in theory create something that resembles a source-map that maps lexed markdown to some subset of a dom tree through an intermediate representation, like http://www.jsonml.org/ but it seems like ridiculous overkill.

that said, for dedicated client-side markdown, my favorites from everything i've searched so far would be these with a live result on the side

• markdowndeep: http://www.toptensoftware.com/markdowndeep/dingus
• codemirror: http://codemirror.net/mode/gfm/index.html
• rover-editor: https://github.com/kasparsd/rover-editor

[murphyslaw]

+1

[tnypxl]

+1

[felipellrocha]

+1

[lolmaus]

I am looking for a WYSIWYG editor identical to Redactor but with one difference. When switching to code, you see Markdown instead of HTML. Thus, editor's features are limited to the ones supported by Markdown.

This would let users input text in either WYSIWYG mode or Markdown mode, depending on their liking.

Is this thread of any help to me?

[tnypxl]

Nope. You're just going told that Markdown is too difficult to support and
doesn't promote the core strengths of Redactor. I've essentially given up
on Redactor supporting Markdown.

On Wed, Feb 19, 2014 at 11:10 AM, lolmaus notifications@github.com wrote:

I am looking for a WYSIWYG editor identical to Redactor but with one
difference. When switching to code, you see Markdown instead of HTML. Thus,
editor's features are limited to the ones supported by Markdown.

This would let users input text in either WYSIWYG mode or Markdown mode,
depending on their liking.

Is this thread of any help to me?

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

[lolmaus]

Are there any other WYSIWYG-to-Markdown solutions?

[treefitty]

I have searched the land far and wide for a Markdown WYSIWYG editor and found nothing, zip, ziltch, nadda. This lead me to develop my own which I can't release at the moment as the code belongs to the company I work for and not open source (yet anyway.... but don't hold your breath either)

I can say having gone down the route of writing this editor that it was waaaay more of an undertaking than I initially expected. Some words of advice to others pursuing this route:

• Allow for time, lots and lots of time
• Create oodles of unit tests
• Use Rangy js, it'll solve loads (not all though) of cross platform issues and get you reasonable IE8 support to boot
• Create the editor with the notion that it is being extremely controlling of the HTML structure to allow clean to/from conversion between markdown. This is the key point and the most difficult as you CANNOT rely on the browser to perform ANY execCommand actions as the HTML structure will not reliably convert to/from Markdown.

Do not underestimate the task of writing a Markdown WYSIWYG editor, it is not for the faint of heart.
I will post back here if/when we decide to release ours to the wild.... but don't count on it, and please don't contact me begging for it :)

[tnypxl]

I'm sure it's hard. I'm not convinced that it isn't worth it.

On Thu, Feb 20, 2014 at 5:11 PM, Paul Carroll notifications@github.comwrote:

I have searched the land far and wide for a Markdown WYSIWYG editor and
found nothing, zip, ziltch, nadda. This lead me to develop my own which I
can't release at the moment as the code belongs to the company I work for
and not open source (yet anyway.... but don't hold your breath either)

I can say having gone down the route of writing this editor that it was
waaaay more of an undertaking than I initially expected. Some words of
advice to others pursuing this route:

• Allow for time, lots and lots of time
• Create oodles of unit tests
• Use Rangy js, it'll solve loads (not all though) of cross platform
  issues and get you reasonable IE8 support to boot
• Create the editor with the notion that it is being extremely
  controlling of the HTML structure to allow clean to/from conversion between
  markdown. This is the key point and the most difficult as you CANNOT rely
  on the browser to perform ANY execCommand actions as the HTML structure
  will not reliably convert to/from Markdown.

Do not underestimate the task of writing a Markdown WYSIWYG editor, it is
not for the faint of heart.
I will post back here if/when we decide to release ours to the wild....
but don't count on it, and please don't contact me begging for it :)

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

[lolmaus]

I'm sorry to join the discussion without reading the whole thread, but what are major difficulties with implementing a WYSIWYG-to-Markdown editor?

My vision:

1. Take an editor that has two modes: WYSIWYG and plaintext (like Redactor).
2. Limit editor's functionality to features supported by Markdown.
3. When switching from plaintext mode to WYSIWYG, use any Markdown JS library to generate HTML and feed it to editor's WYSIWYG engine.
4. When switching from WYSIWYG mode to plaintext mode or when submitting, leverage reMarked.js to generate Markdown from HTML.

It's just a matter of finding a WYSIWYG editor that is decent, is easy to hack into and has a permissive license.

What am i wrong with?

[daGrevis]

The problem is decoding HTML back to Markdown, I believe. It's not as easy as it sounds.

[lolmaus]

@daGrevis
The problem is decoding HTML back to Markdown, I believe. It's not as easy as it sounds.

But there's reMarked.js, and its author @leeoniya is participating in this thread. I've skimmed the thread and there are no mentions that reMarked fails.

All we have to do is to limit the functionality of the WYSIWYG editor, so that it produces HTML simple enough for it not to become different when it's converted to Markdown and back.

[leeoniya]

@lolmaus, yes, the situation is exactly this.

i will say that i've lost much of my former enthusiasm for doing the integration myself since it appears Redactor.js has become primarily a commercial product and this repo is now unmaintained and has effectively been abandoned for all intents and purposes :(

that being said, if you dont need an absolutely bulletproof solution and understand the limits of a back-and-forth conversion and are willing to live with them, integrating marked and reMarked.js with Redactor.js should not take much longer than a few hours to anyone with moderate dev experience.

EDIT: sorry, i meant @lolmaus, not @daGrevis

[treefitty]

@lolmaus the real problems come about with having to maintain such a rigid DOM structure that will support the conversion to and from Markdown. @daGrevis The conversion to/from Markdown is simple and well defined (personally I use the ShowdownJs library from AttackLab https://github.com/coreyti/showdown ... it's awesome, and also converted it to C# for server side conversion).

Back to the editor though, the problem as I say is not just getting a reasonable editor and plugging it into the persistence logic... I started at that place too and quickly realised the errors of my way. The reason this isn't possible is that a WYSIWIG editor will work within the confines of of the rules governing DOM structure.... Markdown is far far far simpler than that. Let's work through some examples:

Consider:

<h1>This is <strong>some important</strong> header with mixed formatting</h1>

Markdown (one of them anyway, because there are many ways one can mark this down!! :)

This is **some important** header with mixed formatting

Now consider the user wants to add the characters ** literally to the header.

The problems escalate from there as to how to restrict the user input in such a way that it will lead to 100% reliable conversion to and from Markdown.
If I were to start over again I would spend more time looking into something like CKEditor and making that more restrictive than starting from scratch myself..... that being said though you would end up with a whole new set of problems, number 1 being that the project is huge and large portions would need to be stripped out; at least taking a clean slate approach allows you to tackle and take control of the problem yourself.

But again it's not easy, my implementation has 2400 lines of complex rule code and 3400 lines of unit tests and it's still not 100% perfect in all cases

Hope this gives a bit more insight

[leeoniya]

@paulcarroll i think you probably went a bit overboard with writing your own editor from scratch, that is indeed a monumental task.

the example you provide isn't a great demonstration of the issues, since markdown provides ways to easily escape special characters with backslashes: http://meta.stackoverflow.com/a/198231 as long as showdown or marked supports unescaping them properly to html.

in fact, if you plug the following into the reMarked.js demo page under "your html", you'll see the escaping happens without problems, i'm sure i missed some characters but it can be added in 5min.

http://leeoniya.github.io/reMarked.js/

<h1>This is <strong>some imp**ortant</strong> header with mixed formatting</h1>

there will definitely be some code to write in order to prevent very deep html nesting an preventing unsupported styles and attributes, but i'm skeptical that it's thousands of lines of code, maybe a few hundred at most, and people can just deal with the 3% edgecases.

EDIT: looks like i support just escaping * and #: https://github.com/leeoniya/reMarked.js/blob/master/reMarked.js#L643 but you can see that adding the rest isnt exactly rocket science.

[treefitty]

@leeoniya I feel justified writing my own editor given the context of the platform we are creating... although admit it is not for everyone (hence my words of caution). The example I gave was a very quickly contrived one at that and I certainly didn't mean to come across as though it can't be solved but more start to draw attention to people in this thread as to the myriad examples of things you will have to handle if you write a WYSIWYG editor... nothing more.

As for your skepticism I completely shared that at one point myself :) I was overwhelmed at just how bad the various browser implementations are surrounding text manipulation.

If you think you can whip up a solution with a few hundred lines of code and "3% of edge cases" then go bananas and contribute it to GitHub.... but I assure you it's not that simple.... I've been there and back! :)

[leeoniya]

admittedly, even reMarked.js breaks in some spectacular ways in <= IE8. i test in latest Chrome and FF and call it a day. i'm sure you're aware that open source doesn't pay like it used to /s

at the same time, one would hope that major editors like Redactor, CodeMirror, TinyMCE, CKEditor, etc, have already solved all the issues you're talking about many times over and have everything abstracted behind sane APIs, so I'm not sure how relevant your encountered problems are to reusing an existing, decent editor.

[treefitty]

Just in closing, the issues I'm referring to are not ones that need to be solved by any of those editors as they are a requirement in maintaining a DOM structure that is conducive to conversion to/from Markdown.

[leeoniya]

i implemented a bi-directional markdown demo cause it was just too easy not to try.

feel free to use this as the basis for further work, but i won't be actively developing it or fixing quirks; you guys are on your own: http://leeoniya.github.io/redactor-js/

fork & branch: https://github.com/leeoniya/redactor-js/tree/markdown-panel

the diffs are kinda screwed up, dunno why. probably did the gh-pages orphan branch wrong. the only changes are to index.html, and addition of lib/marked.js and lib/reMarked.js.

peace

[daGrevis]

This is really neat!

[lolmaus]

Ok, now we need a lightweight editor instead of Redactor. The editor should not inject any arbitrary tags, classes and styles. Only pure semantic HTML with minimal set of HTML elements supported by Markdown.

Any recommendations?

[daGrevis]

I don't know how good CodeMirror is for WYSIWYG editor, but it's damn nice for Markdown editing.

http://codemirror.net/mode/markdown/index.html

[lolmaus]

CodeMirror's Markdown syntax highlighting is awesome, but is not a WYSIWYG editor at all. :(

[daGrevis]

Well then we need a WYSIWYG editor (open-source) and CodeMirror editor for Markdown.

[lolmaus]

That's an option, but i think that having to load two editor libraries should be considered excessive.

[daGrevis]

Any recommendations on WYSIWYG editors?

[ekaradon]

You have uikit editor component which is based on codemirror & markdown. It is great... but it lacks some features like image management, text align, and so on...

[mfbx9da4]

+1

I want my clients to use markdown instead of RTE such as tinyMCE. We need support for:

• Bold, italic, justify right etc
• image upload and embed
• youtube url embed
• tables
• custom widget

[lolmaus]

@mfbx9da4 Markdown does not support justify right. You'll still need a WYSIWYG editor for that.