Hacker News Reader

Comment by jhchen | Hacker News Reader

Hey HN - project creator here. Pleasantly surprise to see Quill picked up again on HN. We built Quill to because my previous company needed a modern editor with an API to manipulate the contents (our use case was collaborative coauthoring). Before I left we open sourced Quill and I have been working on it since. I recently posted about Quill’s 1.0 roadmap: http://quilljs.com/blog/the-road-to-1-0/. AMA.

View on HN

Please can you add a function to sanitize the markup from Google Docs and MS Word (The HTML from Google Docs is actually worse than Word!).

One of the companies I work for has members of the public create pages and getting them to submit usable (clean) markup is one of their biggest pains.

Thanks for the great job!

Just recently I, by some means of evil hackery, embedded quill in an Xamarin-based iOS app. Quick, painless and gets the job done 100%. (Sidenote: I proxied the Controls to a native component to make it look .. "more native".) Back to the point: Great component, awesome documentation, highly recommended.

Could you compare and contrast Quill with some of the other editors that have popped up on HN recently? Are there philosophical differences, or major differences in approach between Quill, Trix, and ProseMirror?

I would say the old approach was to add contenteditable=true to a <div>, call execCommand for formatting, and try to fix the issues this would cause. Editors in the last couple of years simply avoid using contenteditable in as many cases as possible. So the major differences would probably be when and where each of these editors tolerate native contenteditable behavior and which implement it themselves. But it's near impossible to not use contenteditable at all and all editors that I know of (including Trix and ProseMirror) use it to some degree.

For example to handle paste, I've found the best way is to detect a paste, shift focus to another invisible contenteditable div, interpret the pasted content, and insert that into the actual editor through the editor's API. That way no weird/unexpected markup ends up in the editor (whether or not the editor also utilizes contenteditable).

Another trend is a focus on the document model, which is the editor's main data structure to keep track of content. Older editors just use the DOM (or HTML strings) and hand that to you as their API. These editors really don't know themselves precisely what content they contain and cannot offer an API for the simple task of inserting text in a specific nth position. Extensibility becomes quite limited and often leads to a lot of edge case code. I think ProseMirror is right to have the document model as a focal point as I've reached the same conclusion with Quill and have worked on to improve for some time now. The upcoming 1.0 version boasts a much more powerful document model that is being open source separately as Parchment.

The company I work for (Beneath the Ink) needed a robust text editor to handle our unique enhancement technology. Quill was the only WYSIWYG that was close enough to do what we needed. Ultimately, we created a private fork of Quill in order to get everything working. Would you guys be interested in select pull requests to fill some of the items we needed?

As long as they are relevant to the general use cases pull requests are always of interest! The develop branch is currently very different from the most recent release due to 1.0 roadmap features so there may need to be a bit of conflict resolution to merge cleanly.

Reply on news.ycombinator.com