Announcing Quill 1.0
quilljs.com
quilljs.com
Feel free to AMA.
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?
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 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:
1. File a bug report so others can reproduce, identify, and fix the issue: https://github.com/quilljs/quill/issues/new
2. Encourage SauceLabs to support Firefox on Android as a testing platform.
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.
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.
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.
[1] http://quilljs.com/docs/modules/toolbar/#container [2] http://quilljs.com/docs/download/ [3] http://quilljs.com/guides/cloning-medium-with-parchment/
<section>
<h1>First Section</h1>
<p>Text...</p>
<p>Text...</p>
</section>
<section>
<h1>Second Section</h1>
<p>Text...</p>
<p>Text...</p>
</section>
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
A simple Quill + Meteor/Firebase bridge could be a pretty great, easy to spin-up, real-time collaborative document editing tool.
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.
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.
Is there any blog post on their design/architecture? I couldn't find one.
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/
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.
In theory it should be possible to integrate file upload and CDN APIs such as Filestack/Filepicker or others.
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.
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).
Does Quill handle this better?
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?)
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.
Ah well, this looks great too :)
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.
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.
[1] http://quilljs.com/guides/cloning-medium-with-parchment/
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
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
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.
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.
Any word on integration with React?
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).
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!
I'm talking about initial messaging communication here. A demo is not for that - that comes after.
I'm looking for an editor that does not chew up CPU/RAM like Atom.