Editor feature

[begedin]

Moving this here from the gist, so we can have it more easily accessible

Options

Ember.js Wysiwyg Component with Summernote

• http://hbrysiewicz.github.io/2014-04-18-summernote-ember-wysiwyg.html
• Seems like something along the lines of cl/ckeditor or TinyMCE. Typical rich text editor

  Ember Simple Wysiwyg component

• http://indexiatech.github.io/ember-components/#/component/component.wysiwyg/simple
• Simpler, seems cleaner, but for some reason, doesn't support changing styles on selected test. You select a style, then type in that style

  Using a markdown processing library with some simple helpers we can implement

• https://github.com/showdownjs/showdown is a good library
• https://github.com/jpadilla/ember-poe is an example of how that library was used to create a markdown editor
• With the adition of some custom buttons/controls, we could roll out something of our own
• https://github.com/pixelhandler/blog is an example of something like this being done

  Ace with ember-ace-editor

• http://hbrysiewicz.github.io/2014-04-22-ace-ember-editor.html
• http://ace.c9.io/
• Code focused

  CodeMirror with ivy-codemirror

• https://codemirror.net/
• https://github.com/IvyApp/ivy-codemirror
• Also code focused
• Used by Ghost blogging platform - the platform actually has its own component which wraps code mirror, so we can use it as an example

  Thoughts

• Overall, I'm leaning towards something markdown based
• An inline editor insted of one that's input/preview based is a probably a user-friendlier option, but also more difficult to implement right.
• If I had to choose, I'd go with CodeMirror, either with the ivy-codemirror ember addon, or something of our own making, based on how Ghost does it.

[begedin]

List of editors from SO

http://stackoverflow.com/questions/6756407/what-contenteditable-editors-are-there

[joshsmith]

Very solid research on this @begedin.

I lean very heavily in the direction of a Medium-like front-end. Not full WYSIWYG, but something drastically simplified. I'm pretty sour on Markdown because it's kind of painful to write, and even more painful to read and edit. It's okay for small amounts of documentation like a README, but anything larger and longer than that, or that has to be edited often, and it becomes arduous for me.

I'd be very interested in the document/editing structure and architecture that Medium uses. The front-end work around the editor seems hard but achievable, but the document structure itself is a black box to me.

[joshsmith]

After much searching, I found it: https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480

[joshsmith]

@idelahoz and I have had a long conversation in Slack about this. Did some deep reverse engineering and really like their approach.

[begedin]

I took a look at some editors that support "inline" editing. I didn't completely understand from the discussion if we want to try to implement something of our own, or repurpose something existing, but here's what I found:

Aloha Editor 2 (in alpha)

• Link, Demo
• Offers a basic set of styling options, similar in scope to that which Medium uses with their editor
• Seems relatively lightweight (140kb total, minified)
• Runs fast and smooth
• Looks nice, UI easily customizable
• In alpha
• No photo insertion yet
• Does not rely on contentEditable API

Etch

• Link, Demo
• Relies on contentEditable API
• Requires Backbone
• Looks pretty good, but Aloha looks better and I don't think it's an option due to requiring backbone (and some other stuff).

CKEditor

• Link, Demo
• Uses contentEditable for inline editing
• I have some experience with it
• Feels extremely heavyweight, relies on some very specific approaches in configuration, I honestly don't think it's the way to go.
• I do kind of like the approach of editable areas, so the whole document looks like a magazine print. Could be useful for writing note-style documents.

FreshEditor

• Link, Demo
• Very, very basic. Not something we should consider, in my opinion
• I can see the value in using it to understand how creating an inline editor would work in the first place

Hallo

• Link, Demo
• Basic, but has a unique feature - you can edit inline directly, or edit the markdown source
• If we ever want to offer the choice of writing markdown to more advanced users, we may wont too look into how this editor handles it

Mercury

• Link, demo allows you to edit the home page itself
• Is a Ruby gem,
• Has all the basic editing features
• Supports drag and drop image upload and insertion, can handle the backend if used as ruby gem
• Not sure how easy would be to integrate it with a separate client/api, but it is possible
• Overall, very feature packed, but might be overkill

TinyMCE

• Link, Demo
• Pretty much the same stuff that applies to CKEditor also applies here, except it's perhaps slightly less heavy

MediumJS

• Link, demos are on the page
• Claims their aim is to emulate the editor medium.com uses, but it's not quite there yet, in my opinion
• Still, it looks pretty good overall and claims to produce clean content

Redactor

• Link, demo integrated
• Seems clean, not too heavy weight, customizable
• Has all the basic features
• Has image drag and drop

Thoughts

Out of these above, I'm leaning strongest towards Aloha based on UI alone, though it doesn't have all the features we'd want yet. For instance, image drag and drop doesn't work yet. Outside of that, i'd probably go with Redactor or Mercury, followed by MediumJS, in order of preference.

[begedin]

Copied from https://gist.github.com/begedin/8aaecc4fe5681b1ea5af

Options for image uploading with medium-editor

What's supported and what isn't.

At the moment, medium-editor allows dropping an image into the editor area in order to add it to the document. However, this works via base64 image embedding, which isn't optimal and I'm guessing we don't wont.

This feature also does not work when pasting image files (file path is pasted instead), or image clipboard data (nothing happens).

What can we do

For UI-based image uploads

medium-editor does support extensions.

You can define a simple button extension which modifies the selection automatically, or a form extension, which first shows a form and then does something based on our interaction with the form.

What we could do is define our own form extension. The extension allows us to browse for an image and upload it. Upon upload, it replaces the selection with an image tag containing an url to the image. The obvious problem here is that the medium-editor toolbar is selection-based, meaning we still need to select a piece of text to insert the image, which is a bit unintuitive. Even the default image button already present in the editor, works by simply wrapping a selection into an image tag, meaning it also needs a selection to work with.

There are probably ways around it, but nothing satisfyingly straightforward enough.

For dropping from the file system into the editor

We need to somehow override the default behavior of embedding the image as base64. Since image-dragging is already an extension, we should be able to write our own, so I'm not expecting this to be too hard. We could reuse the uploading logic we implement in the image upload button.

For pasting from the file system

I don't think this is possible due to browser security limitations. At least, I wasn't able to find a method of doing it.

GitHub doesn't support this either, nor do a bunch of other services I tried out.

For pasting image data from clipboard

We can again implement our own paste plugin which overrides the default paste extension provided by medium-editor.

Once we do that, we will have access to the editedPaste event, where we can do the following:

• Check if element is image by checking event.clipboardData.items[0].type. It's a MIME type so we will need a list of supported types or we can just check the first part, since they all start with image/*.
• Use event.clipboardData.items[0].getAsFile() to get a Blob object with the pasted content
• Upload to the API
• Insert an <img> tag with the proper src once the upload is complete

It may even be possible to insert some placeholder text while the upload is being performed, similar to how github does it.

Future-proofing

medium-editor does this thing where it maps some default dom events onto custom events specific to this library. For instance, paste gets wrapped into editablePaste, etc.

This means all of our extension stuff will be bound to this specific library instead of working in a more general manner.

I could look into hooking into these events directly and handle image stuff through the component instead of through the medium-editor library and then just make lightweight extension wrappers for the editor itself, which encapsulats this general behavior. That way, when we make the switch to something else, which we likely will eventually, it's easier to keep the behavior.

I'm not sure how viable that is, though. It might proove too difficult.