16 ms·

Markdownify

204 points by tibastral2 12y ago

gpmcadam 12y ago
The problem which this is trying to solve is that clients like WYSIWYG and developers want control over their markup. But, why not make a simple WYSIWYG -> Markdown editor? I've never found an elegant and mature editor which does this
- emp_ 12y ago
  While the opposite of your suggestion, the side by side editor -> preview (like Atom has) is so elegant to me.
  - teleclimber 12y ago
    Really? When I re-read in the preview window and spot a typo I naturally click in the preview window to set the caret there. But of course nothing happens. I have to map what I am seeing on the right to what is on the left, find the typo again, and then do the fix. To each their own but I find it to be awful UX.
    - dredmorbius 12y ago
      Smarts in the preview pane to reposition to the selected point in the edit file would be useful. Highlighting corresponding text -- e.g., highlight a passage on preview and have the editor scroll to the top of that section and highlight it.
- mynegation 12y ago
  I was wondering about the solution to this very problem. I, personally, like the approach of markdown and live-updated rendered HTML side-by-side with toolbar buttons for markup, the approach that MarkdownPad[1] takes. [1] http://markdownpad.com/ http://markdownpad.com/
- talles 12y ago
  This. I'm still waiting for an editor that let's swap editing between WYSIWYG and raw markup (for Markdown). (I could try to do it myself, but I'm not much of a front-end guy).
- pothibo 12y ago
  WYSIWYGs have its own set of problems and this is why most popular websites have WYSIWYG editor but do have Markdown. Some issues: - Portability - Error prone (want to close a bold style but can't unless you copy/paste text) - Doesn't work well on mobile/tablet - Clutter the HTML as the rendering of WYSIWYG needs a lot of wrapper
  - blumkvist 12y ago
    >this is why no popular websites have WYSIWYG editor but do have Markdown. huh?
  - debaserab2 12y ago
    Both Wordpress and Gmail have full blown wysiwyg, and many other sites such as facebook and Twitter have wysiwyg-like features in their messaging/commenting. What site bigger than these use markdown?
    - pothibo 12y ago
      Wordpress WYSIWYG (TinyMCE) is notorious for bugs - I experienced them first hand - and it's not a website, it's a software people install. Big difference. I had forgotten about Gmail, so I guess this is the exception to the rules. On the other hand, markdown is supported on Reddit, Stack Overflow, Github, and many more.
      - debaserab2 12y ago
        Stack Overflow and Github's primary audience is developers. Reddit's started out with a mostly developer audience and still today has a huge crossover. It absolutely makes sense to support mark down if your audience is developers. I don't find gmail to be an exception to the rule at all - all the big webmail providers offer full WYSIWYG support.
    - calebegg 12y ago
      What "wysiwyg-like" features do Twitter and Facebook have? I'm not aware of any.
- bambax 12y ago
  A few years ago I developed a rich text to markdown converter, completely client side in the browser: http://markitdown.medusis.com http://markitdown.medusis.com It could be a first step to build what you're descibing.
ben336 12y ago
> Clients always want wysiwyg editors and you know that's bad for them Not a fan of wysiwyg, but a bit arrogant no?
- ics 12y ago
 Or tongue-in-cheek.
- Raphmedia 12y ago
 No. All the wysiwyg I used are very bad. Even as a dev knowing what's up, I wouldn't use them. What you see is very pretty, <w:ptab alighment="RIGHT" relativeto="MARGIN" leader="DOT">but what you get is very ugly </w:ptab>
 - alextgordon 12y ago
 The only person reading that markup is a computer... If it works, use it. If it's visually broken, don't. All else being equal, pick the best user experience (i.e. not the one that breaks when grandma types in an asterisk).
 - Raphmedia 12y ago
 I wish. But really, it mess up a lot of thing. Styles may be wrongly applied, javascript may bind to the wrong dom elements, etc. Most of the time, everything look really good in the wysiwyg box but breaks in the website. That empty tag might have a padding that adds extra whitespace on the website. Perhaps you added a <h1> or <h2> tag without noticing and this empty tag gets added to your navigation as an empty element. I worked on a project where the user was using and modifying the same content page for the last 5 years. The page was glitchy as hell. Trust me, it didn't even look like HTML anymore. Hell, at first glance the whole HTML code looked like a big regex.
 - m_mueller 12y ago
 I really have to wonder why wysiwyg is so difficult on the web when it's a solved problem on Desktop. I recommend looking at what markup iWorks Pages produces when you export to html - it's quite clean. Why not making a simple wysiwyg that 1) doesn't do any styles, it just operates using pure html tags. So no font for example. 2) cleans up empty tag as soon as possible (but at the latest when you hit save). 3) treats newlines as follows: single newline = , double newline = new tag. Regarding tags there is exactly two states: Having one open and having none open. Does it really have to be that hard?
rspeer 12y ago
I love this approach. I've seen too many double-pane markdown editors, which strike me as an uninspired, bloated interface. Markdown is already readable! You don't need to waste half your interface on a preview that's visible all the time, when you can just syntax-highlight the Markdown to be its own preview.
- mynegation 12y ago
  Markdown by itself _is_ pretty readable. Ultimately, you want to have it rendered though. This is why live preview helps me a lot. Markdown, while readable by itself, has many gotchas that may screw up the rendered result: newline here, wrong indentation there, forgot to put pipe symbol in the table etc etc. It is much easier and faster to catch these things right away than after the fact. I compare this to the on-the-fly syntax check in IDEs that saved me countless compile-and-fix cycles and boosted my productivity tremendously.
  - ergothus 12y ago
    ...which is why the above poster recommended syntax-highlighting. Not raw MD, but not double the output space either.
- robbiep 12y ago
  It depends. I'm building interfaces that have non technical users and being able to have preview is important. Having said that I can't find anything that is easily integratable with flask so I think I will go with this for now
- brute 12y ago
  The best interface I have seen yet allows you to switch between source and rendered text on a paragraph-to-paragraph basis[1]. There is really no reason why the text you are currently NOT editing should not be rendered. Unfortunatly this approach is a little bit more challenging to implement, why so few editors use it. That said, I fully agree with your stance on double-pane editors. [1] http://www.inkcode.net/qute http://www.inkcode.net/qute
marcinbejm 12y ago
Would upload to s3 work?
- giaour 12y ago
  For images? That would imply that you'd be serving your images directly off s3, which is more expensive than Cloudinary. Since the project is less than 100 lines of code, I bet you could customize the image uploader to fit your needs.
vortico 12y ago
This is fantastic! I've seen a few of these WYSYWYG-like Markdown editors, but I like this because it doesn't come with an ugly toolbar and has automatic list, numbered list, and quote insertion upon typing the return key.
fortawesome 12y ago
You might want to consider changing the name. It's not great practice to use the name of someone else's open source thing to name yours. It's fine in the tagline.
- prezjordan 12y ago
  A little confused here, what open source thing are they basing the name off of?
  - klausa 12y ago
    Markdown.
  - rezistik 12y ago
    I thought this was a Browserify extension from the naming convention personally. Not that that is enough of a reason to change the name.
  - pacofvf 12y ago
    there is a PHP and python "Markdownify" , both are HTML to Markdown converters, so they are different to this project, there is no Markdownify in the JS world that I'm aware of. A better name could be WYMIWYG, "What you markdown is what you get" :P
    - tibastral2 12y ago
      WYAIWYPF (what you accept is what you pay for :))
    - rambambam 12y ago
      It sounded so familiar, that name. Thanks for pointing out, you are right.
- adamkochanowicz 12y ago
  Don't agree.
amelius 12y ago
Funny, this is the kind of solution that programmers come up with (as opposed to UI designers).
luchosrock 12y ago
Codemirror is such a great peace of code!
Stoo 12y ago
Storytella[0] takes the same approach. It uses a Markdown editor in a single pane, no preview, which is also based on CodeMirror[1]. CodeMirror makes this kind of editor straight forward to build, with a lot of configuration and extension options. This seems to hide a lot of the configuration, so I would think is great for dropping into new admin or comment systems where you need rich text but don't want to allow arbitrary HTML. I would consider switching over to it, as it would mean less code for me to manage, but I'd need the CodeMirror extensibility exposed. (disclosure, I built Storytella) [0] https://storytel.la/ https://storytel.la/ [1] http://codemirror.net/ http://codemirror.net/
- kaoD 12y ago
  I tried building something similar to your product a couple years ago, but found CodeMirror syntax highlighting lacking since you couldn't style multiple lines which seemed like a must for Markdown. E.g. try setex headers: Header ====== Only the ===== are styled as a header in Markdownify. Did you manage to solve it in Storytella? (too lazy to sign up and check myself, sorry.)
  - Stoo 12y ago
    I've always used the starting hash header form: # Header ## Header So I haven't come across that issue before. Thanks for pointing out a possible issue!
  - Stoo 12y ago
    I've just had a look at the Storytella editor using the === style of headers and it doesn't work. You can see it for yourself in the editor demo, here: https://storytel.la/demo/chapters/edit/ https://storytel.la/demo/chapters/edit/
debaserab2 12y ago
> Clients always want wysiwyg editors and you know that's bad for them, so this is a great compromise for them and for you So far any time Ive released a content editing text area that uses markdown to the mass public, it's resulted in everyone treating it like a normal text box because they don't want to learn markdown. Wysiwyg editors, as much as we hate them, always gets much better adoption.
- roc 12y ago
  Markdown is primarily for writerly writers with workflows. That's where all the benefits accrue. That's where it matters whether mark-up is done inline with content creation, or whether it's a post-pass process of fiddly buttons and menu options. That's where it matters whether the mark-up is lightweight, or overbearing. That's where it matters whether formatting is treated consistently from one piece of software to the next, or a constant surprise. That's where it matters whether the resulting file is locked away in a proprietary binary format, or not. Etcetera. If you're building a proprietary end-to-end service -- for editing a little bit of text, storing that text, and then displaying that text -- whether your solution incorporates markdown is, at best, probably irrelevant.
  - slowmovintarget 12y ago
    I'm nodding my head in agreement to the points you make and wondering why we're not having the conversation about AsciiDoc instead, especially with regard to the constant surprise you mention. http://www.methods.co.nz/asciidoc/index.html http://www.methods.co.nz/asciidoc/index.html
buro9 12y ago
**foo*f**f* The WYSIWYG should be closer to the Preview for these messy cases.
raldu 12y ago
Isn't a specialized "editor" is antithetical to the very idea behind Markdown, which is to make written text as readable as possible both in plain text and the web? Markdown syntax is already too simple. The original authors even mention "plain text e-mail" as their biggest source inspiration. [1] [1]: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/
- wetmore 12y ago
  The text is still readable as plaintext, but I think you could concede that styling it a bit does make it easier to see the effect of your markdown. It's like how, say, Sublime text has a syntax highlighter for markdown files. Sure, you could argue that is enough to signify that the contained text is bold, but it's hard to deny that also bolding that text in the editing stage is helpful. Syntax "highlighting" like in OP's editor will always provide more than just plain text formatting can. So it's not really antithetical anyway. Sure, markdown is made to make written text as readable as possible in plain text, but that doesn't mean it can't be even more readable in a non-plain text setting.
- kordless 12y ago
  I think the idea is that the web is used as a content creation tool, so we need a simple tool, on the web, to do markdown creation.
- saidajigumi 12y ago
  No, of course not. While Markdown is plain text, it is a markup language with its own syntax. This syntax is parsed by tools to transform Markdown into other formats. As it happens, this is analogous to code: encoded as text with a specific syntax. As such, "markdown editors" are for the most part text editors with syntax highlighting. The syntax is important because it encodes the user's intent beyond the raw text bytes. Just as with code editor's highlighters, we use them because it provides an immediate and useful visualization of our intent. "Why isn't my link highlighted? OH, missed that paren." "Why is everything italic? OH, fat-fingered the closing asterisk." So while well-formatted Markdown happens to also be well-formatted plain-text, but that doesn't mean that good authoring tools aren't needed or helpful.
tumbling_stone 12y ago
I use SpaceGray theme in Sublime Text which provides syntax highlighting for markdown, which I simply adore and find indispensable. One thing I always missed in it was the better formatting of different headers, I am glad to see this and other features implemented so properly.
rachelandrew 12y ago
I would love to see a really good WYSIWYG-like thing that creates Markdown. I'm one of the founders of Perch (http://grabaperch.com http://grabaperch.com) and we have almost 6 years of experience with Perch - and many more of creating custom CMS solutions before launching Perch. We've always tried to get people to write Textile or Markdown. When we were developing custom solutions we actually had pretty good success with getting our clients to use Textile, once we'd explained the benefits. With Perch we ship our default templates (which are really just samples) using the MarkItUp editor and set to use Markdown, and not allow HTML. However it's all configurable and we offer editor plugins so people can switch to using Redactor, CKEditor, TinyMCE or create their own editor plugin. In discussing this stuff with our customers who are developing sites for clients, it's not something that inserts HTML that they want. They just don't want the end client to see the Markdown as they don't think they will cope. I think there is often an assumption that they won't cope, but for whatever reason they end up installing CKEditor or whatever and it allows in a load of junk markup. This makes me sad. So, an editor that created Markdown yet allowed for some sort of preview of how things will look I can see the benefit of, if just to encourage confidence in not using things that allow inserted HTML.
- teleclimber 12y ago
  Personally I completely understand end-users for wanting a purely visual writing environment. No "show HTML", no markdown codes (and escape characters!) etc.. There is a reason desktop writing applications became fully visual three decades ago! The value of Markdown is that it defines a limited set of semantic blocks and text styles so that the markup and css needed to render the content is finite and predictable upfront. It seems to me this advantage could be achieved with an editor designed specifically with this idea in mind. The editor could be fully visual, but it would respect a pre-defined set of rules regarding content semantics. The editor could output an XML or JSON tree of content with semantic labels that you could then run through a markup generator. That way you have full control over the markup. Once you have that you no longer need to limit yourself to what markdown offers. Maybe you want to give authors the ability to create "warning" and "tip!" blocks when writing help manuals for example. If you define those blocks then the editor would allow the author to insert them.
fny 12y ago
There's a lovely app for OS X called Mou that does this quite well: http://25.io/mou/ http://25.io/mou/
- doomspork 12y ago
  I recently switched to MacDown which is influenced by Mou and open source, it's great: http://macdown.uranusjr.com/ http://macdown.uranusjr.com/
rhythmvs 12y ago
Great work! Always happy to see people working towards a WYSIWYG editor for Markdown. I did a similar project¹, with strong focus on editing math, inline, and “real time” wysiwyg. It failed. The problem is that most such approaches treat Markdown as _code_ instead of _text_, and inevitably mistake syntax highlighting for semantic, text-driven styling (as if one would style nouns, verbs, adjectives, instead of <h1>, , , etc.). Thus they use a code editor such as CodeMirror (like this one does, too). And then you must style `.cm-` syntax markers instead of the eventual (html) nodes that would be the output of a real Markdown parser. Which makes it impossible to just throw in any arbitrary html5 css-stylesheet. Which is imho the whole point of wysiwyg Markdown editing. What you’d really want instead is true Markdown parsing, which normalizes the user’s input into a parse tree, then renders to clean html. But syncing input and output over an AST is quite impossible as long as Shadow DOM is not available in browsers. Cfr interesting discussion, over at Github (re: Quill editor).² As for Markdown parsers: there’s many of them. The OP’s project uses @chjj’s marked.js³: wouldn’t harm to mention that on the homepage or in the README, since behavior (markdown interpretation) is very different from parser to parser. (I used to maintain a repo which lists all available Markdown parsers, apps, etc.)⁴ Meanwhile there’s CommonMark⁵, of course, which has already some really fast implementations in JavaScript. (Plus, they’re “Standard” ;-)⁶ Would be nice to see one of the CommonMark reference implementations incorporated into a WYSIWYG editor like this one. ¹ https://github.com/rhythmus/mathdown https://github.com/rhythmus/mathdown ² https://github.com/quilljs/quill/issues/74#issuecomment-42942223 https://github.com/quilljs/quill/issues/74#issuecomment-4294... ³ https://github.com/chjj/marked https://github.com/chjj/marked ⁴ https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources ⁵ http://commonmark.org http://commonmark.org ⁶ https://news.ycombinator.com/item?id=8264733 https://news.ycombinator.com/item?id=8264733
fiatjaf 12y ago
People are not born knowing how to use WYSIWYG, they learn it, and it is not easy, it is not more "natural" than writing Markdown or any other thing.
thebouv 12y ago
I think I may be in the minority for just not liking Markdown in general. I don't understand the hub-bub around it.
- tracker1 12y ago
  People tend to like it because it's plain text, easy enough to sanitize input, represents most of the typical syntax people already used for a generation in marking up plain text. Doesn't require knowledge of HTML tags, and doesn't introduce the copy-paste pain that WYSIWYG editors introduce.
- voyou 12y ago
  The thing I dislike about the hubub around Markdown is the incredible poverty of ambition. No-one has yet quite nailed the perfect web-based editor for the kind of styled text we've had in printed matter for 500 years; apparently, because of this, we're all supposed to be excited about an ugly hack for representing styled text which is arbitrarily limited by the computer systems of the 1970s. Sorry, I want something better than that.
dheera 12y ago
Call me crazy but I still can't see what all the hype is with Markdown, BBcode, and all these other formatting languages that come out every few years. What ever was wrong with just defining and using a subset of HTML?
- joliv 12y ago
 Markdown and its kin are easier to read raw. Surrounding underscores, for example, break flow much less than tags.
 - dheera 12y ago
 Interesting. Perhaps readability-wise yes, but in terms of actually writing it, I always find myself googling Markdown cheatsheets because I can't remember for the life of me whether single-asterisk or double-asterisk is bold or italic (the HTML counterparts are hard to screw up), and what the assortment of other symbols do. Like, my brain's parser wants to explode. Also, * in Markdown appears to map to HTML , , and <li> and this drives me nuts, especially when these have to be used together.
 - roryokane 12y ago
 You can produce <li> with ‘-’ instead of ‘*’. ‘-’ has no other meaning.
wodenokoto 12y ago
I failed to see any mention of iPython notebook which does the same thing. Who borrowed from whom?
- roryokane 12y ago
  Perhaps the author independently invented the technique. Or perhaps he copied it from one of the other editors that highlight Markdown like this, such as Mou, MacDown, or Sublime Text and Emacs when using certain themes.
camillomiller 12y ago
That's great. One thing: You may want to know that the link input is broken on the iPad. If you already have an open keyboard, you can't insert text on the alert form.
enupten 12y ago
Meh. Still doesn't come anywhere close to Emacs and Org-mode.

204 points by tibastral2 12y ago

The problem which this is trying to solve is that clients like WYSIWYG and developers want control over their markup. But, why not make a simple WYSIWYG -> Markdown editor? I've never found an elegant and mature editor which does this

emp_ 12y ago
While the opposite of your suggestion, the side by side editor -> preview (like Atom has) is so elegant to me.
- teleclimber 12y ago
  Really? When I re-read in the preview window and spot a typo I naturally click in the preview window to set the caret there. But of course nothing happens. I have to map what I am seeing on the right to what is on the left, find the typo again, and then do the fix. To each their own but I find it to be awful UX.
  - dredmorbius 12y ago
    Smarts in the preview pane to reposition to the selected point in the edit file would be useful. Highlighting corresponding text -- e.g., highlight a passage on preview and have the editor scroll to the top of that section and highlight it.
mynegation 12y ago
I was wondering about the solution to this very problem. I, personally, like the approach of markdown and live-updated rendered HTML side-by-side with toolbar buttons for markup, the approach that MarkdownPad[1] takes. [1] http://markdownpad.com/ http://markdownpad.com/
talles 12y ago
This. I'm still waiting for an editor that let's swap editing between WYSIWYG and raw markup (for Markdown). (I could try to do it myself, but I'm not much of a front-end guy).
pothibo 12y ago
WYSIWYGs have its own set of problems and this is why most popular websites have WYSIWYG editor but do have Markdown. Some issues: - Portability - Error prone (want to close a bold style but can't unless you copy/paste text) - Doesn't work well on mobile/tablet - Clutter the HTML as the rendering of WYSIWYG needs a lot of wrapper
- blumkvist 12y ago
  >this is why no popular websites have WYSIWYG editor but do have Markdown. huh?
- debaserab2 12y ago
  Both Wordpress and Gmail have full blown wysiwyg, and many other sites such as facebook and Twitter have wysiwyg-like features in their messaging/commenting. What site bigger than these use markdown?
  - pothibo 12y ago
    Wordpress WYSIWYG (TinyMCE) is notorious for bugs - I experienced them first hand - and it's not a website, it's a software people install. Big difference. I had forgotten about Gmail, so I guess this is the exception to the rules. On the other hand, markdown is supported on Reddit, Stack Overflow, Github, and many more.
    - debaserab2 12y ago
      Stack Overflow and Github's primary audience is developers. Reddit's started out with a mostly developer audience and still today has a huge crossover. It absolutely makes sense to support mark down if your audience is developers. I don't find gmail to be an exception to the rule at all - all the big webmail providers offer full WYSIWYG support.
  - calebegg 12y ago
    What "wysiwyg-like" features do Twitter and Facebook have? I'm not aware of any.
bambax 12y ago
A few years ago I developed a rich text to markdown converter, completely client side in the browser: http://markitdown.medusis.com http://markitdown.medusis.com It could be a first step to build what you're descibing.

ben336 12y ago

> Clients always want wysiwyg editors and you know that's bad for them Not a fan of wysiwyg, but a bit arrogant no?

ics 12y ago
Or tongue-in-cheek.
Raphmedia 12y ago
No. All the wysiwyg I used are very bad. Even as a dev knowing what's up, I wouldn't use them. What you see is very pretty, <w:ptab alighment="RIGHT" relativeto="MARGIN" leader="DOT">but what you get is very ugly </w:ptab>
- alextgordon 12y ago
 The only person reading that markup is a computer... If it works, use it. If it's visually broken, don't. All else being equal, pick the best user experience (i.e. not the one that breaks when grandma types in an asterisk).
 - Raphmedia 12y ago
 I wish. But really, it mess up a lot of thing. Styles may be wrongly applied, javascript may bind to the wrong dom elements, etc. Most of the time, everything look really good in the wysiwyg box but breaks in the website. That empty tag might have a padding that adds extra whitespace on the website. Perhaps you added a <h1> or <h2> tag without noticing and this empty tag gets added to your navigation as an empty element. I worked on a project where the user was using and modifying the same content page for the last 5 years. The page was glitchy as hell. Trust me, it didn't even look like HTML anymore. Hell, at first glance the whole HTML code looked like a big regex.
 - m_mueller 12y ago
 I really have to wonder why wysiwyg is so difficult on the web when it's a solved problem on Desktop. I recommend looking at what markup iWorks Pages produces when you export to html - it's quite clean. Why not making a simple wysiwyg that 1) doesn't do any styles, it just operates using pure html tags. So no font for example. 2) cleans up empty tag as soon as possible (but at the latest when you hit save). 3) treats newlines as follows: single newline = , double newline = new tag. Regarding tags there is exactly two states: Having one open and having none open. Does it really have to be that hard?

rspeer 12y ago

I love this approach. I've seen too many double-pane markdown editors, which strike me as an uninspired, bloated interface. Markdown is already readable! You don't need to waste half your interface on a preview that's visible all the time, when you can just syntax-highlight the Markdown to be its own preview.

mynegation 12y ago
Markdown by itself _is_ pretty readable. Ultimately, you want to have it rendered though. This is why live preview helps me a lot. Markdown, while readable by itself, has many gotchas that may screw up the rendered result: newline here, wrong indentation there, forgot to put pipe symbol in the table etc etc. It is much easier and faster to catch these things right away than after the fact. I compare this to the on-the-fly syntax check in IDEs that saved me countless compile-and-fix cycles and boosted my productivity tremendously.
- ergothus 12y ago
  ...which is why the above poster recommended syntax-highlighting. Not raw MD, but not double the output space either.
robbiep 12y ago
It depends. I'm building interfaces that have non technical users and being able to have preview is important. Having said that I can't find anything that is easily integratable with flask so I think I will go with this for now
brute 12y ago
The best interface I have seen yet allows you to switch between source and rendered text on a paragraph-to-paragraph basis[1]. There is really no reason why the text you are currently NOT editing should not be rendered. Unfortunatly this approach is a little bit more challenging to implement, why so few editors use it. That said, I fully agree with your stance on double-pane editors. [1] http://www.inkcode.net/qute http://www.inkcode.net/qute

marcinbejm 12y ago

Would upload to s3 work?

giaour 12y ago
For images? That would imply that you'd be serving your images directly off s3, which is more expensive than Cloudinary. Since the project is less than 100 lines of code, I bet you could customize the image uploader to fit your needs.

vortico 12y ago

This is fantastic! I've seen a few of these WYSYWYG-like Markdown editors, but I like this because it doesn't come with an ugly toolbar and has automatic list, numbered list, and quote insertion upon typing the return key.

fortawesome 12y ago

You might want to consider changing the name. It's not great practice to use the name of someone else's open source thing to name yours. It's fine in the tagline.

prezjordan 12y ago
A little confused here, what open source thing are they basing the name off of?
- klausa 12y ago
  Markdown.
- rezistik 12y ago
  I thought this was a Browserify extension from the naming convention personally. Not that that is enough of a reason to change the name.
- pacofvf 12y ago
  there is a PHP and python "Markdownify" , both are HTML to Markdown converters, so they are different to this project, there is no Markdownify in the JS world that I'm aware of. A better name could be WYMIWYG, "What you markdown is what you get" :P
  - tibastral2 12y ago
    WYAIWYPF (what you accept is what you pay for :))
  - rambambam 12y ago
    It sounded so familiar, that name. Thanks for pointing out, you are right.
adamkochanowicz 12y ago
Don't agree.

amelius 12y ago

Funny, this is the kind of solution that programmers come up with (as opposed to UI designers).

luchosrock 12y ago

Codemirror is such a great peace of code!

Stoo 12y ago

Storytella[0] takes the same approach. It uses a Markdown editor in a single pane, no preview, which is also based on CodeMirror[1]. CodeMirror makes this kind of editor straight forward to build, with a lot of configuration and extension options. This seems to hide a lot of the configuration, so I would think is great for dropping into new admin or comment systems where you need rich text but don't want to allow arbitrary HTML. I would consider switching over to it, as it would mean less code for me to manage, but I'd need the CodeMirror extensibility exposed. (disclosure, I built Storytella) [0] https://storytel.la/ https://storytel.la/ [1] http://codemirror.net/ http://codemirror.net/

kaoD 12y ago
I tried building something similar to your product a couple years ago, but found CodeMirror syntax highlighting lacking since you couldn't style multiple lines which seemed like a must for Markdown. E.g. try setex headers: Header ====== Only the ===== are styled as a header in Markdownify. Did you manage to solve it in Storytella? (too lazy to sign up and check myself, sorry.)
- Stoo 12y ago
  I've always used the starting hash header form: # Header ## Header So I haven't come across that issue before. Thanks for pointing out a possible issue!
- Stoo 12y ago
  I've just had a look at the Storytella editor using the === style of headers and it doesn't work. You can see it for yourself in the editor demo, here: https://storytel.la/demo/chapters/edit/ https://storytel.la/demo/chapters/edit/

debaserab2 12y ago

> Clients always want wysiwyg editors and you know that's bad for them, so this is a great compromise for them and for you So far any time Ive released a content editing text area that uses markdown to the mass public, it's resulted in everyone treating it like a normal text box because they don't want to learn markdown. Wysiwyg editors, as much as we hate them, always gets much better adoption.

roc 12y ago
Markdown is primarily for writerly writers with workflows. That's where all the benefits accrue. That's where it matters whether mark-up is done inline with content creation, or whether it's a post-pass process of fiddly buttons and menu options. That's where it matters whether the mark-up is lightweight, or overbearing. That's where it matters whether formatting is treated consistently from one piece of software to the next, or a constant surprise. That's where it matters whether the resulting file is locked away in a proprietary binary format, or not. Etcetera. If you're building a proprietary end-to-end service -- for editing a little bit of text, storing that text, and then displaying that text -- whether your solution incorporates markdown is, at best, probably irrelevant.
- slowmovintarget 12y ago
  I'm nodding my head in agreement to the points you make and wondering why we're not having the conversation about AsciiDoc instead, especially with regard to the constant surprise you mention. http://www.methods.co.nz/asciidoc/index.html http://www.methods.co.nz/asciidoc/index.html

buro9 12y ago

**foo*f**f* The WYSIWYG should be closer to the Preview for these messy cases.

raldu 12y ago

Isn't a specialized "editor" is antithetical to the very idea behind Markdown, which is to make written text as readable as possible both in plain text and the web? Markdown syntax is already too simple. The original authors even mention "plain text e-mail" as their biggest source inspiration. [1] [1]: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/

wetmore 12y ago
The text is still readable as plaintext, but I think you could concede that styling it a bit does make it easier to see the effect of your markdown. It's like how, say, Sublime text has a syntax highlighter for markdown files. Sure, you could argue that is enough to signify that the contained text is bold, but it's hard to deny that also bolding that text in the editing stage is helpful. Syntax "highlighting" like in OP's editor will always provide more than just plain text formatting can. So it's not really antithetical anyway. Sure, markdown is made to make written text as readable as possible in plain text, but that doesn't mean it can't be even more readable in a non-plain text setting.
kordless 12y ago
I think the idea is that the web is used as a content creation tool, so we need a simple tool, on the web, to do markdown creation.
saidajigumi 12y ago
No, of course not. While Markdown is plain text, it is a markup language with its own syntax. This syntax is parsed by tools to transform Markdown into other formats. As it happens, this is analogous to code: encoded as text with a specific syntax. As such, "markdown editors" are for the most part text editors with syntax highlighting. The syntax is important because it encodes the user's intent beyond the raw text bytes. Just as with code editor's highlighters, we use them because it provides an immediate and useful visualization of our intent. "Why isn't my link highlighted? OH, missed that paren." "Why is everything italic? OH, fat-fingered the closing asterisk." So while well-formatted Markdown happens to also be well-formatted plain-text, but that doesn't mean that good authoring tools aren't needed or helpful.

tumbling_stone 12y ago

I use SpaceGray theme in Sublime Text which provides syntax highlighting for markdown, which I simply adore and find indispensable. One thing I always missed in it was the better formatting of different headers, I am glad to see this and other features implemented so properly.

rachelandrew 12y ago

I would love to see a really good WYSIWYG-like thing that creates Markdown. I'm one of the founders of Perch (http://grabaperch.com http://grabaperch.com) and we have almost 6 years of experience with Perch - and many more of creating custom CMS solutions before launching Perch. We've always tried to get people to write Textile or Markdown. When we were developing custom solutions we actually had pretty good success with getting our clients to use Textile, once we'd explained the benefits. With Perch we ship our default templates (which are really just samples) using the MarkItUp editor and set to use Markdown, and not allow HTML. However it's all configurable and we offer editor plugins so people can switch to using Redactor, CKEditor, TinyMCE or create their own editor plugin. In discussing this stuff with our customers who are developing sites for clients, it's not something that inserts HTML that they want. They just don't want the end client to see the Markdown as they don't think they will cope. I think there is often an assumption that they won't cope, but for whatever reason they end up installing CKEditor or whatever and it allows in a load of junk markup. This makes me sad. So, an editor that created Markdown yet allowed for some sort of preview of how things will look I can see the benefit of, if just to encourage confidence in not using things that allow inserted HTML.

teleclimber 12y ago
Personally I completely understand end-users for wanting a purely visual writing environment. No "show HTML", no markdown codes (and escape characters!) etc.. There is a reason desktop writing applications became fully visual three decades ago! The value of Markdown is that it defines a limited set of semantic blocks and text styles so that the markup and css needed to render the content is finite and predictable upfront. It seems to me this advantage could be achieved with an editor designed specifically with this idea in mind. The editor could be fully visual, but it would respect a pre-defined set of rules regarding content semantics. The editor could output an XML or JSON tree of content with semantic labels that you could then run through a markup generator. That way you have full control over the markup. Once you have that you no longer need to limit yourself to what markdown offers. Maybe you want to give authors the ability to create "warning" and "tip!" blocks when writing help manuals for example. If you define those blocks then the editor would allow the author to insert them.

fny 12y ago

There's a lovely app for OS X called Mou that does this quite well: http://25.io/mou/ http://25.io/mou/

doomspork 12y ago
I recently switched to MacDown which is influenced by Mou and open source, it's great: http://macdown.uranusjr.com/ http://macdown.uranusjr.com/

rhythmvs 12y ago

Great work! Always happy to see people working towards a WYSIWYG editor for Markdown. I did a similar project¹, with strong focus on editing math, inline, and “real time” wysiwyg. It failed. The problem is that most such approaches treat Markdown as _code_ instead of _text_, and inevitably mistake syntax highlighting for semantic, text-driven styling (as if one would style nouns, verbs, adjectives, instead of <h1>, , , etc.). Thus they use a code editor such as CodeMirror (like this one does, too). And then you must style `.cm-` syntax markers instead of the eventual (html) nodes that would be the output of a real Markdown parser. Which makes it impossible to just throw in any arbitrary html5 css-stylesheet. Which is imho the whole point of wysiwyg Markdown editing. What you’d really want instead is true Markdown parsing, which normalizes the user’s input into a parse tree, then renders to clean html. But syncing input and output over an AST is quite impossible as long as Shadow DOM is not available in browsers. Cfr interesting discussion, over at Github (re: Quill editor).² As for Markdown parsers: there’s many of them. The OP’s project uses @chjj’s marked.js³: wouldn’t harm to mention that on the homepage or in the README, since behavior (markdown interpretation) is very different from parser to parser. (I used to maintain a repo which lists all available Markdown parsers, apps, etc.)⁴ Meanwhile there’s CommonMark⁵, of course, which has already some really fast implementations in JavaScript. (Plus, they’re “Standard” ;-)⁶ Would be nice to see one of the CommonMark reference implementations incorporated into a WYSIWYG editor like this one. ¹ https://github.com/rhythmus/mathdown https://github.com/rhythmus/mathdown ² https://github.com/quilljs/quill/issues/74#issuecomment-42942223 https://github.com/quilljs/quill/issues/74#issuecomment-4294... ³ https://github.com/chjj/marked https://github.com/chjj/marked ⁴ https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources ⁵ http://commonmark.org http://commonmark.org ⁶ https://news.ycombinator.com/item?id=8264733 https://news.ycombinator.com/item?id=8264733

fiatjaf 12y ago

People are not born knowing how to use WYSIWYG, they learn it, and it is not easy, it is not more "natural" than writing Markdown or any other thing.

thebouv 12y ago

I think I may be in the minority for just not liking Markdown in general. I don't understand the hub-bub around it.

tracker1 12y ago
People tend to like it because it's plain text, easy enough to sanitize input, represents most of the typical syntax people already used for a generation in marking up plain text. Doesn't require knowledge of HTML tags, and doesn't introduce the copy-paste pain that WYSIWYG editors introduce.
voyou 12y ago
The thing I dislike about the hubub around Markdown is the incredible poverty of ambition. No-one has yet quite nailed the perfect web-based editor for the kind of styled text we've had in printed matter for 500 years; apparently, because of this, we're all supposed to be excited about an ugly hack for representing styled text which is arbitrarily limited by the computer systems of the 1970s. Sorry, I want something better than that.

dheera 12y ago

Call me crazy but I still can't see what all the hype is with Markdown, BBcode, and all these other formatting languages that come out every few years. What ever was wrong with just defining and using a subset of HTML?

joliv 12y ago
Markdown and its kin are easier to read raw. Surrounding underscores, for example, break flow much less than tags.
- dheera 12y ago
 Interesting. Perhaps readability-wise yes, but in terms of actually writing it, I always find myself googling Markdown cheatsheets because I can't remember for the life of me whether single-asterisk or double-asterisk is bold or italic (the HTML counterparts are hard to screw up), and what the assortment of other symbols do. Like, my brain's parser wants to explode. Also, * in Markdown appears to map to HTML , , and <li> and this drives me nuts, especially when these have to be used together.
 - roryokane 12y ago
 You can produce <li> with ‘-’ instead of ‘*’. ‘-’ has no other meaning.

wodenokoto 12y ago

I failed to see any mention of iPython notebook which does the same thing. Who borrowed from whom?

roryokane 12y ago
Perhaps the author independently invented the technique. Or perhaps he copied it from one of the other editors that highlight Markdown like this, such as Mou, MacDown, or Sublime Text and Emacs when using certain themes.

camillomiller 12y ago

That's great. One thing: You may want to know that the link input is broken on the iPad. If you already have an open keyboard, you can't insert text on the alert form.

enupten 12y ago

Meh. Still doesn't come anywhere close to Emacs and Org-mode.