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?
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/