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.
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?
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.
"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"
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.
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.
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.
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.
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.
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.
[+] [-] jhchen|9 years ago|reply
Feel free to AMA.
[1] http://quilljs.com/blog/the-road-to-1-0/
[+] [-] Tloewald|9 years ago|reply
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.
[+] [-] scottmessinger|9 years ago|reply
[+] [-] BafS|9 years ago|reply
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?
[+] [-] whatnotests|9 years ago|reply
This being HN and all, I'd like to use this myself but the first thing I would want to add to my toolbar is "preformatted" or "code" styling.
Can we get an example of that hooked up in the default "Playground" codepen?
[+] [-] cwisecarver|9 years ago|reply
[+] [-] alien3d|9 years ago|reply
[+] [-] pfooti|9 years ago|reply
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.
0: https://github.com/quilljs/parchment
1: https://github.com/ottypes/rich-text
2: https://github.com/ericeslinger/delta-transform-html
[+] [-] sampl|9 years ago|reply
A simple Quill + Meteor/Firebase bridge could be a pretty great, easy to spin-up, real-time collaborative document editing tool.
[+] [-] neoCrimeLabs|9 years ago|reply
[+] [-] hhandoko|9 years ago|reply
[+] [-] nacs|9 years ago|reply
[+] [-] awgneo|9 years ago|reply
[+] [-] wwalser|9 years ago|reply
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.
Kudos on the project and 1.0 release.
[+] [-] erlend_sh|9 years ago|reply
[+] [-] devilsenigma|9 years ago|reply
Is there any blog post on their design/architecture? I couldn't find one.
[+] [-] rtcoms|9 years ago|reply
[+] [-] jhchen|9 years ago|reply
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.
[1] https://github.com/basecamp/trix#different-by-design [2] http://quilljs.com/docs/modules/
[+] [-] vikrantrathore|9 years ago|reply
[+] [-] sideproject|9 years ago|reply
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.
[+] [-] delibes|9 years ago|reply
In theory it should be possible to integrate file upload and CDN APIs such as Filestack/Filepicker or others.
[+] [-] lobster_johnson|9 years ago|reply
[+] [-] jhchen|9 years ago|reply
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.
[+] [-] paulddraper|9 years ago|reply
Ah well, this looks great too :)
[+] [-] jacquesc|9 years ago|reply
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.
[+] [-] pfooti|9 years ago|reply
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.
[+] [-] jhchen|9 years ago|reply
[1] http://quilljs.com/guides/cloning-medium-with-parchment/
[+] [-] jrgoj|9 years ago|reply
[+] [-] alphaomegacode|9 years ago|reply
Don't know if I'm doing something wrong but if you enter something like this: 3tan(x/2) + 4 = 0, the x/2 renders just like that versus 'vertically'.
Great release nonetheless
[+] [-] jhchen|9 years ago|reply
[1] https://khan.github.io/KaTeX/
[+] [-] Scarbutt|9 years ago|reply
[+] [-] cyberferret|9 years ago|reply
[+] [-] jelder|9 years ago|reply
[+] [-] jhchen|9 years ago|reply
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.
[1] https://github.com/quilljs/parchment [2] http://quilljs.com/docs/api/ [3] https://facebook.github.io/draft-js/docs/overview.html
[+] [-] malloryerik|9 years ago|reply
Any word on integration with React?
[+] [-] jhchen|9 years ago|reply
[+] [-] zem|9 years ago|reply
[+] [-] tmat|9 years ago|reply
[+] [-] kingofhawks|9 years ago|reply
[+] [-] abritinthebay|9 years ago|reply
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).
[+] [-] strictnein|9 years ago|reply
[+] [-] jhchen|9 years ago|reply
[+] [-] finid|9 years ago|reply
I'm looking for an editor that does not chew up CPU/RAM like Atom.
[+] [-] sampl|9 years ago|reply