Hey HN - Quill maintainer here. The 1.0 release has been a huge effort with spanning almost a year, over a thousand commits, and hundreds of issues closed, since it's announcement[1].
I note that (at least in the playground example) there's zero attention paid to accessibility (e.g. how would someone know the "bold" button is the "bold" button?).
Also (and kind of related) is there an option that is completely free of UI implementation (outside the editable region)? Almost any project will have its own UI libraries and foibles, and I don't think it's a good idea to force your own UI library into the mix.
The playground favors very short code for experimentation, given the limited screen real estate for the split view.
Quill could do better in the accessibility front though and autofill titles and aria attributes for you. However at the moment you would have to create an HTML element with the aria attributes and pass that into the toolbar[1]. Please feel free to open a feature request for tracking.
You can also use Quill without either of its themes or any of its UI by just using quill.core.js and quill.core.css[2]. The Cloning Medium with Parchment guide[3] in fact starts with this and builds custom UI on top of quill.core.js/quill.core.css.
In the comments, you mention how Quill is extensible. Does Quill's extensibility enable the creation of a hierarchical level that resembles an HTML <section> element? From what I can tell, Quill/Parchment divides documents into block blots, inline blots, and embedded blots[1]. If I wanted to create a group of block blots, could that be done with Quill? In HTML, this would look something like:
I have tried quite a few others editors on mobile (android Firefox) but none of them seems to work correctly, Quill is much better but still has some issues (for eg. If I type 'qwe' I have 'weq'), will you take in account the mobile browsers for the future development? Or what is/are the worst limitations/bugs?
I'm sorry you are experiencing problems on your device/browser but I don't think it's fair to say Quill does not take mobile browsers into account.
I personally have a Nexus 7 running Android 5.1, which I use to test Chrome and Firefox. I also have an iPad and iPhone that I use to test Safari. Quill works great in all of these platforms. Quill also uses SauceLabs to automate testing of every push. I have filed browser bugs in the past on mobile Firefox, but have been told sometimes the issue is from the keyboard driver itself, which is two layers from the browser. With the distribution of Android versions and the differences between devices, it is cost prohibitive for an open source project to test and catch all Android issues.
Of course none of this explanation helps your particular situation. What you can do to help your particular situation is:
It's very difficult to make a fully working browser/webview based editor on Android. Every keyboard interacts with applications differently, sometimes differing significantly between keyboard versions. I think a rewrite of the Android keyboard composition interface is needed. Most of the issues occur because the keyboard needs to keep track of the document state itself, and has race conditions/inconsistencies with the editable which maintains the "true" state.
All web based rich text editors on Android right now (Quill, Draft.js, Dropbox Paper, Quip, etc.) have similar problems. One easier to reproduce problem is to make a list and then exit the list by pressing enter twice. The next time you backspace a few characters, the composition will be messed up (cursor will jump around, characters get duplicated, etc.) There are other issues too--oftentimes the keyboard will lose focus, backspacing will paste in characters, jumping cursors, etc. These issues are keyboard/browser version specific too, most of them disappear if you use Samsung's keyboard instead of the Google one.
For Quora's Android editor I spent some time fixing all the issues I could find with the latest Google keyboard+WebView, and fixed the majority. I built the open source version of Google's keyboard (LatinIME), and a fork of Chromium (Crosswalk) for the WebView so that I could debug both, which worked pretty well. Then, Google updated the keyboard which introduced bugs, but didn't update the open source project, making it difficult to fix the new issues. There's also a separate rewrite in Chromium to use a separate thread for the IME, which will change behavior again.
I confirm, it is my keyboard (Swifkey) who creates those issues, it works smoothly with the default one. Thank you for your explanations and sorry if my feedback was a bit harsh :)
As a long-time user of Quill, I must say: Congratulations to jhchen and everyone else who worked on the project.
I use Quilljs because it's a great implementation of a modern-thinking WYSIWYG text editor. The underlying parchment[0] library helps a lot to separate out the data model from the rendered view (instead of relying on contenteditable to handle your data model, like many other classic rich text editors do). My users type stuff in Quill, and my front end shoots data in the rich-text[1] format back to the back-end. I have a small (and not great, but functional for my needs) library [2] I wrote to convert rich-text back into HTML, so we never actually store user-entered HTML entities in our database (which helps a lot for things like protecting against XSS attacks, and since rich-text is just a JSON object, I can do interesting database queries that are a bit trickier to pull off if it had been HTML).
On top of all of that, Quill emits delta objects on user interaction (that conform to an operational transform model), so it's pretty straightforward to wire it into a concurrent editing system. This isn't batteries-included (you have to deal with resolving the operational transforms yourself, which is of course tricky) but it's a great start in that direction.
Before the document format was added to sharedb I found it real easy to transform quill deltas into sharejs ops. Sharejs has a fuzzer you can use to test things like that, which was invaluable, but I want to stress how little work it was getting them to talk to each other. It'll be even less now
"Announcing Quill 1.0" is such a nondescript title that tells nobody what Quill actually is. Why not make the title something like "Announcing Quill 1.0, web based WYSIWYG text editor"
Correct me if I am wrong (it does happen), but I have seen titles edited for clarity regularly on HN.
Also, many titles are context sensitive. For example, if you're reading the title on the Quill website, chances are you already know what Quill is - or do you? When you copy the title verbatim to something like HN, the context is completely lost to anyone who doesn't already know what Quill is. In other words matching the title doesn't benefit anyone when the title is meaningless without context.
I just added Quill to a side project site a few days ago, having spent almost three months comparing different WYSIWYG editors. So many of these libraries have gotten bloated over the years or simply have too many bugs. Quill just works for me all of the time. Definitely check it out!
Having spent literal years creating and maintaining large WYSIWYG projects based on TinyMCE and CKEditor, I can not sing the praises of the latest iteration of these editors highly enough. Between sidestepping contenteditable almost entirely and maintaining a behind the scenes source-of-truth they really have created a compelling and usable experience in all modern browsers. Something I always aimed for but always knew was another year of work away.
Tiny was actually a well written project and several of the maintainers were exceptional programmers and designers. I think they saw the way out but were never able to get there because of the sheer number of features they would have had to build parity for in order to ship something new. Not to mention the fact that 5 years ago old versions of IE would have still been in the picture.
Disclosure: As the maintainer of Quill, I am much more aware if its strengths and have worked hard to limit its weaknesses.
The main idea behind Trix as stated in their README[1]:
"Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs... Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all."
I think the first portion is only historically true. Everyone has figured out contenteditable/execCommand alone is a problem and all notable editors I have seen released in the past few years have reasonable solutions--Trix's solution included. Quill is slightly different in that it prevents problematic operations in the first place and reimplements them itself, such as enter and backspace, but the main idea is the same: maintain a document model as the source of truth, define operations to mutate it, and build an editing experience on top of this.
Some strengths unique to Quill:
* API Quill has the most powerful API of any editor I have seen. You can make any text or formatting change in any part of the editor at any time. Trix by contrast only allows changes to the current selection.
* Modules Quill's internals are broken into modules[2] that themselves can be configured or even swapped out. Many modules also include their own APIs. Trix does not have documentation in this regard, but looking at its codebase, it does not appear designed to support major modification of its internals.
* Formats/Content Quill's document model itself is customizable, which allows users to define their own formats or customize existing ones. This capability is what kicked of 1.0 development, now being released today. This gives Quill extensive coverage of well known formats (tables to my knowledge is the only missing one), but more exotic formats/content like formulas, tweets or syntax highlighted code is also supported. Some editor frameworks have this same idea, but lack the actual editor and UI on top of this so you have to build a big portion of functionality to realize the full benefits.
One main idea I'd like to highlight is this: Text is no longer written to be printed. It is written to be rendered on the web—a much richer canvas than paper. Quill 1.0 was designed and built to support this next generation canvas.
I have a use case where I need to copy in large quantities of content and have them display nicely. At the moment we are using Redactor which is broken in many respects.
I have been using your test form and it appears to play much more nicely with the sort of data that we get.
We do have lots of table data.
Would you contact me (in sig) to discuss further?
Trix is better as it works with new web components standard, quill does not support shadowDom in chrome and doesn't follow current web components standard, check https://github.com/quilljs/quill/issues/904 for details. It will create issues when used in web components project.
I noticed how adding an image doesn't actually upload it to the server, but rather encodes it - which becomes a very large text. What implication does that have? What if I have a very large text with many images?
I've been using CKEditor, which has been somewhat of a go-to text editor for many and it's been around for many years. Its image uploading seems to work relatively well.
There was a separate comment about Draft, so I answered that one there and will just comment on ProseMirror here.
ProseMirror's main is insight is the need to maintain a document model in parallel with the actual DOM. While most modern editors also do this, ProseMirror also allows their document model to be extended and customized, which only Quill and possibly Draft[1] is also capable of. I think this is the right idea and foundation to build on top of (Quill also made this choice).
I don't think it's fair to judge implementation or specifics beyond its ideas just yet since it is still in the development stages and things can change and improve, as stated on its README:
"NOTE: This project is in BETA stage. It isn't thoroughly tested, and the API might still change across 0.x releases. You are welcome to use it, but don't expect it to be very stable yet."
[1] "Possibly" because Draft uses inline styles and only two levels of content (block and inline) so it's far more limiting.
Thanks. One issue I believe ProseMirror has yet to solve well is the concept of embeddable widgets.
For example, I should be able to embed a "video object", which represents some content that isn't directly editable, and which may exist somewhere else, and is perhaps internally represented using opaque ID that references some backing store. I want to be able to render this as a nice little video renderer that has a little edit button or a context-menu, and which can be edited to change its size, select a time subrange, subtitles and so on. The document editor should treat it as an opaque object that can render itself and marshal/unmarshal itself somehow, and which can be copied, pasted and moved around. Ideally it should also be possible to offer UI interactions, such as mouse clicks (for resizing).
Quill does let you define Embed blots which essentially hand back complete control over the corresponding DOM node container. For example the formula module uses KaTeX to render formulas and it does not care what KaTeX does to descendant DOM nodes. You could attach listeners and add editing UIs within this if desired. I believe this approach should allow you to implement what you are describing.
Looks to me like a big difference is that Quill is HTML/DOM-oriented, whereas ProseMirror has a generic document model that is format-agnostic and allows custom parsing/serialization.
Well, as far as I can tell, Quill doesn't have a document model as such. It only has a flat sequence of deltas, which are runs of text with associated formatting attributes.
ProseMirror, on the other hand, explicitly defines a document model as part of its API, arranged as a tree (DAG). This implies you can do things like represent LaTeX natively without having to flatten it, thus preserving the original structure. For example, an entire \section or \chapter could be a single node. (I don't know if this works in practice.) In theory, its design doesn't require a hard distinction between "text" and "embeds" because everything is both.
The benefit is that don't need a complicated, potentially lossy translation between the flat and non-flat versions. For example, if you're doing LaTeX, and there's a \title and \author in the document, you could keep this around as non-visible nodes that are preserved in the model and get serialized back when you export the edited document. (To be fair, I don't know if Quill supports invisible embeds, perhaps it does?)
Most editors nowadays maintain a parallel structure to the DOM. And since the DOM is a tree, that structure is also a tree. Quill's is Parchment[1] and goes a step further by also having an API and allow defining new nodes, which ProseMirror (and maybe Draft) also does.
Deltas are a simple, iterable output format for Quill. In practice it is much nicer to deal with this in many use cases than the Parchment tree.
I tried Quill out a couple months ago, but dropped it after I spent days trying to get @mentions working with no luck.
Has been very difficult to find a solid js library to handle Facebook/Github style @mentions and autocompletes. Anyone able to get mention support working with Quill?
I've used at.js several times and have found it to be a buggy, ugly codebase. I wouldn't recommend it.
I've ended up manually handling @mentions on my own by writing a quill plugin (unfortunately the plugin is closed-source for now), but basically it amounts to:
Create a new parchment format to represent the atmention data, and how it should be rendered. In my case, I also flagged it as read-only (because in ours, @username ends up rendering as a styled User Actual Name once it's done being selected, and I didn't want to allow users to edit the name displayed).
Create a widget that inserts that @mention formatted text in the quill data model.
Figure out when to trigger the widget. I listen to document deltas, and decide when the user has inserted a character inside a word that is at least four characters long and starts with an @, and then pop up the menu which I populate with users who match the text that's entered so far.
I ended up rolling my own because stuff like at.js is pretty heavyweight, and probably every system has its own constraints on atmentions (how to populate the username list, formatting for the list itself (avatars or no?), what to do on atmention-insert (notifications processing), and how to represent an atmention in finished text). So I found it was way easier to do it on my own, since the only thing I was really getting from something like at.js was a pop-up autocomplete list anyway, and those are pretty trivial to do in either vanilla javascript with css show/hide stuff, or (in my case, angular 1.x) in your already-existing front end framework.
Not sure which version you were using, but it would be difficult to add this in pre-1.0, and one of the reasons 1.0 was built. There were definitely documentation gaps during the 1.0 beta and release candidacy as well so I'd encourage you to give Quill and its docs another look. Cloning Medium with Parchment[1] might be a relevant guide.
One editor feature I've been looking for is the ability to lock down a region of text so that the user can drag the region around within the text or add text before/after the text. However, the contents of the region can't be edited nor deleted.
It's not terribly difficult, but it's hard to make it work nicely owing to the quirks of contenteditable regions. Personally, I think that if you're serious about writing a rich text editor for the browser you should avoid using contenteditable (as per Google Docs, for example) which lets you do pretty much anything. There are plenty of reasonably decent contenteditable-based editors out there, and they're all similarly broken when you get to difficult stuff.
Draft’s own description of itself is "Rich Text Editor Framework for React" and is more comparable with Parchment[1], both being a foundation in which you can build a rich text editor. But there are many pieces missing for it to be a full fledged editor like Quill.
* UI Draft only has buttons you can toggle for formats. There are no dropdowns to select which header size—just six h1, h2, h3, h4, h5, h6 buttons. There are no tooltips or link, video, or image UIs to assist with editing.
* API - Quill’s API is designed for the editing use case. Draft is built on React and inherits many primitives and ideas that are more appropriate for websites, rather than linear content like text. Which APIs is nicer for which use case may be subjective so I will just link Quill’s API’s [2] and Draft’s API [3] and ask the reader to think of some common tasks, like making a range of text bold, and try to figure out how to accomplish these tasks from reading through the respective APIs.
* Markup - With the exception of nested lists, Quill’s markup is clean and semantically correct. Draft uses <span> tags with inline styles with lots of attributes for bookkeeping.
I'm not sure these points are fair...like you said Draft is a primitive to build editors and has much less out of the box, so it's not a good comparison. However:
* Draft does not only have buttons for toggling formats - it has nothing. The point is that you can build a UI and functionality around it to do arbitrarily complex things with it. The way it's described here makes it sound like the entirety of what you can do with Draft is toggle formats, which is not at all true. Like you said this is where Draft and Quill become most apples and oranges, it becomes a trade-off between finer grain control and more functionality out of the box.
* Agreed that API preference is subjective, Draft definitely has some parts of its API that could be more clear or could be better aligned with what it's trying to accomplish.
* A really important thing to note with markup that's misrepresented here is that Draft doesn't output that markup as a result - it's only used to render the content in the editor. The content is stored in an immutable data structure that lets you leverage a ton of React's upsides in terms of rendering performance. That structure can also be easily turned independent of the rendered UI into clean HTML to be persisted.
I do not believe it is a fine control vs out of the box tradeoff. Draft gives you one. Quill gives you both. Previously Quill was limited in what content it could understand but this is the major change in 1.0. I'd encourage you to take another look.
Regarding the third point on markup, everything you say is true, except the first part about misrepresentation. When I said markup I am precisely talking about the HTML markup used to render the contents of the editor. Some people do care about the HTML markup being semantic during the edit session. Sounds like you don't or are okay with computing this yourself, and that's fine, but again this is extra work for the end user. Quill also has an internal state[1] that is easy to iterate over and convert into whatever output/markup.
Quill definitely has users that are on React (and Angular, Ember, etc). In general you will want a React Component that is essentially a wrapper around Quill so they stay out of each other's way. You should make sure to understand React's component lifecycle and follow their best practices on working with third party libraries that modify the DOM.
That said - as someone unfamiliar with the project it took me FAR too long to work out (by reading the site) that it's not a text editor in the Sublime/Atom/etc sense and in fact a different kind of library like the TinyMCE type things.
Except better.
I think it could be much clearer from the home page what exactly Quill does (and what it does is fantastic).
I was actually just going to post a question asking if there's a write up on how this compares to Sublime and Atom. Never crossed my mind that it was an improved TinyMCE after glancing through the website.
The demo on the homepage looks and seems nothing like a demo. I had no clue I could edit the content until i read this comment and started clicking around.
Also, the interactive playground DOES make it seem like it is trying to be a code editor, except it is implemented in codepen which is pretty confusing. I get that you're showing how to render the JS and all but only because I've spent time poking around a lot.
That all said, next time I need a WYSIWYG I know exactly where to go! Thanks!
Quill is a rich-text WYSIWYG editor library for end-users who want to format text on websites. You would use it to clone Google Docs, for ex. It's not really an editor you would want to write code in.
Those two are implemented with contenteditable, which is a very flawed mechanism that isn't standard or consistent across browsers. Quill is implemented entirely in JS.
Thank you. I'm going to check it out. Both TinyMCE and CK work well if we have a handful of these on the page. But anything more than that, it becomes a mess and drags the page down :(
I believe Quill relies on contenteditable in order to support certain operations, such as pasting. Quill has its own document model, and supports things like deltas/operational transforms, which are practically impossible if you use the DOM as the truth like TinyCKE et al do.
It relies on contenteditable. You can just paste any old thing into it — not sure whether some stuff gets stripped by the document model, but that's kind of beside the point. Once you use contenteditable you get a whole bunch of weirdness for free.
Feel free to AMA.
[1] http://quilljs.com/blog/the-road-to-1-0/