Quill – An Open Source Rich Text Editor with an API
quilljs.com
quilljs.com
I have high hopes for what these guys produce.
EDIT: Just wanted to add that looking through the API docs, it seems to solve exactly the problems I had. Would have made a measurable difference to my business to have had this, if it does what it says it does.
Stypi was acquired by Salesforce in 2012 but we continued to work on Quill because we felt it was a missing piece of the web. We're now working for GoInstant (also acquired by Salesforce in 2012), who are also working on some very cool stuff.
Quill was originally called Scribe but then another editor released a bit ago with the same name so we changed it to Quill.
Granted, it's been a few years so this might be solved by now, but to me the final solution was WYMeditor [0]. It makes sense too - user should enter content and mark it as title / text / subtitle, add images and similar... but the design of the final page should be left to designer, not to user. What if you want to change the design sometime later?
Blogmask is an interesting side project but I don't have much time for it. Always looking for open-source contributors though.
using https://github.com/leeoniya/reMarked.js and https://github.com/chjj/marked
may just have to do this after work today if no one gets to it first.
Throw in a ShareJS script to autosave [2], an it's even more awesome!
[2] https://gist.github.com/josephg/1341527
Relevant Githubs:
- https://github.com/quilljs/quill
- https://github.com/josephg/ShareJS
Edited: to account for leeoniya's explanation that follows
EDIT: and to really come full circle, instead of rendering the markdown in a plain textarea like the example, render it inside of Codemirror with syntax coloring.
the ms markup is often much larger than the content
I will be very happy if this turns out to work as good as it looks at a first glance.
Realistically though will probably end up adding all of the common formats leaving just custom ones for the user. But even custom ones should be simple. For example all we did to define a custom authors format in the Authorship module was quill.addFormat('editor', { class: 'author-' }).
Better documentation (and more predefined formats) to come!
I love scribe, it's the most consistent of all the editors I have tried (and I have pretty much tried them all). Would love to see image support though. I know there is a pull request pending for some time on this issue but hope it can make it to the core. Even nicer would be to have hover controls on inserted image (using shadow DOM I presume) that allow modifying its attributes (right/left align, alt text etc).
Having that footer be a fixed overlay may be fine on giant desktop monitor, but the website is pretty terrible on a smaller one.
edit: I stand corrected. It stays awful no matter what the screen size...
We realize and apologies for the lack of documentation for modules. One reason is the module interface is not finalized because we're not sure what the community will dream up and wanted to get feedback before making a decision that might unintentionally exclude certain use cases or encourage unsustainable designs. Depending on what's decided we will probably add functionality to the existing image tooltip. We'd love for you to be involved in the discussion if this is an area of interest.
I couldn't figure out how to remove a URL from a selection of text.
It would be awesome to see an example of how to let the user upload an image.
If you highlight the text, and click the link hyperlink icon in the toolbar, the URL will be removed. The link overlay UI doesn't support that though; we'll add a "remove" action in addition to "change".
I noticed there seems to be support for block level formatting (e.g. "h1"), but it doesn't look like it's been implemented yet. What's your plan for handling bullets, headings, block quotes, and other block level formatting options?
Is there really no way to write a modern rich text editor that remains compatible (and/or degrades gracefully) with slightly older browsers?
If I only select a few words it seems to work though.
And even the 2 clause has the documentation requirement. Different projects interpret it different ways, and many projects ignore it. But, if you have documentation (exactly what is meant by that?), you had better include therein the disclaimers of all the BSD-licensed projects you used. It can be a lot to keep track of.
There are other licenses out there that do a much better job of being liberal. MIT is the most popular, but there's also ISC, Fair, even LGPL, ...
The core value proposition here doesn't require feature-completeness in my opinion; with a great API for modules, table support (for example) could easily be added by a developer. I would encourage the core devs not to build things like that just yet, personally.