EpicEditor: An Embeddable JavaScript Markdown Editor | Hacker News Reader

EpicEditor: An Embeddable JavaScript Markdown Editor

oscargodson.github.com

165 pointsmars27 comments

I'd love to implement this instead of a WYSIWYG into our platform, but the problem is our users (non-technical) are not going to take the time to learn markdown. Even if we had a guide on the right I have a hunch they would still be super confused.

Idea: Add buttons to the top (optional) that LOOK like a WYSIWYG (something they are familiar with), that simply apply markdown around text.

I think you'd see such much wider adoption with that addition, which is something I'd love to happen, because WYSIWYG's do indeed suck.

Agreed 100%. GitHub's wiki UI (example: http://cl.ly/2T2718220P1Y3h0M330r) would be a great place to take inspiration from, since that's almost exactly what you're talking about.

Github's button-bar is nice, but let me throw up another offbeat idea: a hybrid toolbar/cheatsheet. It'd have:

• a toolbar-like row of pulldowns: one for 'range/inline' markup (like bolding), one for 'block/paragraph' markup (like headers, blockquote, code-indent), and one for complicated inserts (like link+linktext, image+alt)

• each pulldown would be filled with side-by-side entries showing both markup and effect, like the best cheatsheet/reference pages are laid out

• selecting a bit of markup would do 'the right thing' with the existing insertion point or selection-range

Thus a user might momentarily click then dismiss the dropdown just to refresh their memory of the syntax, or actually pick from the dropdown for assisted inserts. (If they're regularly picking items, it could reorder by 'frecency' for convenience. If they're usually just looking, it might instead order by some form of 'infrecency' [1] – don't bother showing familiar constructs that have been recently typed.)

[1] At the moment while there are thousands of Google hits for ["frecency"] there are none for ["infrecency"]. It's an infrecently needed concept.

This is something that is planned last I talked with Oscar. I'm sure he'd appreciate the feedback.

Your suggestion might be a good default for handling image insertion. I know markdown, but in instances where I'm specifying an image (e.g. a blog, a CMS page) I'd rather have a button that lets me select from available images than have to type it out using markedown (which would require that I know the filename and explicit path). Not to mention image alignment.

I would have the same challenge - TinyMCE gives me a way to link to other pages (the list of other pages is generated by a script).

I wonder how you could add such help on top of a Markdown editor.

Yep, this is planned once we get cross platform support (still need IE8 and mobile) https://github.com/OscarGodson/EpicEditor/issues/41

Why would you want to force users to use a markup language that, as you say, they have no desire to learn, rather than a simple WYSIWYG editor? How would that make things better for users?

What'd I'd love to see is something that is a WYSIWYG interface for editing Markdown. Markdown is fantastic and awesome because it limits what people can do, but expecting clients to learn it is a pain in the arse.

http://hallojs.org does this, it was on HN yesterday.

Looks great, but by default it subjects the user to the markdown gotcha of wanting to italicize text_with_underscores_in_it. EpicEditor, by contrast, has italicizing underscores_inside_words turned off.

This looks cool, but unfortunately does not work well on touch devices. It looks like the preview and maximize buttons depend on the hover event.

This is the next thing we'll be tackling after IE8 support actually. It'll have a totally custom look for mobile. https://github.com/OscarGodson/EpicEditor/issues/27

Hint: the maximize button splits the screen, and giving you editor/look view (like coffeescript site does for coffee/js).

This is similar in many ways to MarkItUp (http://markitup.jaysalvat.com/), which I've had good experiences with.

One potential pitfall with JavaScript preview of Markdown (or Textile, or any other similar language) is that if you're not using the same script to transform the content at the server side, the final output can contain subtle differences. Not all implementations are precisely equal. If differences do occur, that can be frustrating for the user who just carefully previewed their work.

An alternative (albeit a more resource intensive one) would be to make ajax requests back to the server and have it perform the transformation and return it to the page. Unfortunately, that's probably not going to be satisfactory for realtime previewing.

I used to use MarkItUp but eventually moved away from markdown altogether. I found I had to keep tweaking the parser to allow stuff like inline, floated images, code blocks with language-tagging (for syntax highlighting) and so on. It came to be more work than just using a WYSIWYG editor.

I think it would be better if it offered some way to see a cheat sheet. I don't see that in the initial examples and too lazy to investigate.

That's not really in the scope of the project, but it could certainly be added on.

Was reported today and we responded here: https://github.com/OscarGodson/EpicEditor/issues/148

Nice. MultiMarkdown would be even cooler!

The parser is completely interchangeable, it would be a one line change to make this work (with just about any language you have a parser for).

I have been looking for something like this for a long time. Most certainly I will try this out.

Is the 'epic' supposed to be ironic?

This is brilliant.

very nice!

similar:

http://hallojs.org

That's...fucking awesome.

Reply on news.ycombinator.com