▲ 100 points
back
47 comments
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.
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.
Here's a previous discussion on Quill https://news.ycombinator.com/item?id=7716376 and a recent discussion on Trix, another rich text editor: https://news.ycombinator.com/item?id=10410879
The most comprehensive/updated list of editors I know of is here: https://github.com/cheeaun/mooeditable/wiki/Javascript-WYSIW...
(It doesn't do much to compare/evaluate the options, but it's pretty up-to-date/comprehensive, which is a start)
Thanks for the list. https://github.com/NextStepWebs/simplemde-markdown-editor (not technically a RTE, then) really seems to stand out!
I use quill in my big internal CMS / forum mashup project that's not (quite) ready to share yet. It's pretty rad. There's a related library [0] that is the rich text specification for operational transforms. By wiring the OT stream into a websocket, I can get pretty decent multi-user simultaneous editing on the cheap. It's not perfect - I don't properly handle some cases with simultaneous edits to the same region, but it's good enough to prevent locking and clobbering in a multi-author environment. It also means I have per-keystroke autosave and the ability to reconstruct who typed what in a given document on my site, which is important to some of my users.
The module system is reasonable for adding in extensions as well. I personally don't miss access to tables, since really most of the time tables are misused anyway (for structured presentation of data, there's a ton of times I see tables where bulleted lists or other structures would be a lot more space-efficient anyway). It's on the list of nice-to-have features, but not a requirement.
All of these new browser rich text editors look really nice, but without basic table support there is no way anyone can switch from TinyMCE (which is about as horrible as you can get).
Are tables really hard to support? Every time I see one of these projects I check excitedly if they do but am always disappointed.
Tables are hard to do well and there’s ambiguity as to what constitutes basic. After being able to create an NxM table, should you be able to add/remove rows/columns? What about resizing the width or height of rows or columns. Does using <th> violate the promise of semantic output? Merging rows/columns? And of course now there’s copy/paste support for tables to contend with. What if that table had merging and yours didn’t? Tables also require more complex UI than just a button like most other formats.
But outside of word processing, tables are just not used very much. How many times have you added a table to an email? A task manager description? A blog post? None of the big sites using Quill are clamoring for tables.
For the other newly launched editors out there, I can only imagine they made a similar calculation to not included in the launch shortlist.
> But outside of word processing
I'm not sure what you mean by that, surely word processing is exactly what Quill is meant to be used for? Table use outside of word processing could just be achieved by something other than Quill entirely.
> tables are just not used very much. ... None of the big sites using Quill are clamoring for tables.
That's fair enough, I doubt they would be used in the context of writing an email, blog post (but that is debatable, I often include tables of figures/results) or a task manager description. But there are many, many back office applications that take user input through a WYSIWYG editor and put it into some kind of report. I think tables are critical here (I was also surprised to see nested lists[2] are not supported in Quill, that's also pretty important). Maybe Quill isn't aiming for those kind of use cases though, but it's just such a shame that TinyMCE is the best solution.
It's possible to do right, we used to use Redactor[1] and that handles the basic use cases extremely well while producing super clean output.
I'm not sure if I'm using the terminology correctly but to me Microsoft Word and Google Docs are word processors. They offer a whole new level of formatting capabilities with thousands of options to support that goal, with a feature set so complete they are products all by themselves.
The use cases I mentioned utilizes composing text, but that's not the main product. If you want to build a CMS, add in app messaging, add formatting to textboxes, then Quill could be the answer. If you want to build the next Google Docs, out of the box Quill will probably not be enough.
People working for the NHS or Public Health England would frequently want to share snippets of larger datasets.
My twitter stream is full of people sharing PDFs or charts or links to sites serving excel sheets.
So there's a niche there - people wanting to write a small blog post, and share a small table (no more than 4 x 10) of data.
I think @jhchen does a good job summarizing about why tables are hard. If you absolutely need table support, Froala[1] is the only relatively modern/complete editor I've come across w/ decent table editing, but it's not open source/free. (Aloha v1 has a table plugin, but v2 AFAIK does not. Mercury and Medium Editor (w/ the tables extension) allow insertion, but not editing).
One interesting thing I found looking for table support a while back is that there is a medium-editor-handsontable extension[2]. Something like this w/ the ability to attach a dedicated grid object (or embed a gdoc) is probably the way to go.
[1] https://www.froala.com/wysiwyg-editor
[2] https://github.com/asselinpaul/medium-editor-handsontable
I'll also add that there is an editor that I think basically is the "holy grail":
* super fast/responsive
* inline/contextual UI
* automatic transmogrification (s to ULs, ``` for code blocks, etc)
annotations
* revision tracking
* collaborative editing
* image uploads + formatting
* table insertion + editing
* task lists
* attachments
It's Dropbox's Paper editing component, but I don't think that's going to be open-sourced anytime soon. Maybe ProseMirror, Trix, ContentTools, or Quill or one of the other squajillion editors will get there someday. It really is a shame that there are so many partial solutions out there.
These are not TinyMCE replacements and if you ask me, the trend is that the architecture is going around those huge editors because nobody likes them and nobody wants to use them.
They simply don't have the right thing for their users. They are too complicated for the end user and if you know how to write HTML, you don't even need it, it just complicates things.
Is there a gzipped CDN version? The [URL](http://cdn.quilljs.com/0.19.10/quill.min.js) provided in the readme is not gzipped.
Thanks for the catch! Looks like my new CDN provider does not provide gzip automatically like my old one. Fixing this now.
A clean, modern RTE has been needed for a long time - would this be the one? Unless of course RTEs are really not needed anymore, which may well be the case.
Perhaps this one: http://prosemirror.net/
Anyway, it would be nice to have at least an overview of the architecture of this editor. I'm a bit hesitant to use an editor as a "black box" plugin, because it means that a minor customization may take days of work (or even tossing away the whole editor) in case the architecture is bad.
Wow, ProseMirror is really great. Thanks for pointing it out! It's wonderful that it uses CommonMark as its document model, and especially that (to quote):"ProseMirror adjusts to your site, not the other way around". :)
Out of curiosity, what are the main use cases for RTE's? I've been using Windows for over 20 years and in that time I can think of only a handful of times I've ever used WordPad.
Websites. RTEs are a necessary evil there. If you want to post some text on your website (an announcement, press release, anything), your options are plain text, RTE, or non-WYSIWYG solutions such as Markdown/HTML, which are far outside a non-technical user's comfort zone. Lots of clients (well, their secretaries) copy-paste articles from Word (sent to them by marketing, sales, legal, press teams) into the website, and that requires an RTE with:
* basic HTML markup (headlines, paragraphs, lists...)
* HTML tables
* images (data:// URIs are good for handling pasted images) and an image/file browser, complete with some image processing that rejects or shrinks down giant images without ruining the image quality, because people will upload giant JPEGs straight from their phone if you let them (naturally, file uploads come with their own cans of worms like server security, disk space, file permissions, growing backups, etc.)
* black magic to cope with Word's markup
Don't forget to make sure that the end result looks consistent with the rest of the site without the users having to manually set the font family/size on all their text... and that the editors can't turn off the RTE and post raw HTML with malicious intent... and a million other things.
Ah, yes that use case makes sense. Thanks.
We've been using Quill with great success on http://www.twlng.com
my company has also: www.getfetcher.com
What kind of markup will this produce? Currently, I'm left guessing as to whether or not it will be the same as I see when I inspect the editor itself. It claims "semantic markup", yet it offers styling tools alongside semantic ones.
It produces "rich text" in a clean JSON format, which is one of Quill's strengths IMO. It's also what enables it to be used for real-time collaborative editing across browsers without any weirdness about HTML normalization.
I use Quill on my site to allow trusted but non-technical users to write rich text. It was easy to configure so it only allows a strict subset of tags. My users have been using it for a few months and haven't managed to slip in any disallowed tags, attributes, or styles.
I did the same. But those non-technical users still ask why they can't paint their text red, right-align paragraphs and insert as many line breaks as their good taste suggests. So it can't really work unless they agree to get a bit technical and understand what semantic markup and CSS are. And then, I'd really prefer to teach them some basic markdown and have them use a markdown editor, only so they can stop believing that "what they see is they get".
It produces semantic markup when it can, but in some cases such as font color, there is no semantic representation so it uses the most cross browser/application implementation, which is inline styles.
Explain what you mean by 'semantic markup'. I find people mean the term in two ways: so trivially it's uninteresting or so unrealistic it's implausible.
In my experience, the most common meaning of 'semantic' is 'non-presentational'. For example:
<font color="#ff0000">hello, world</font>
I'd concur that is a good example of 'non-semantic' but what's trickier is to agree on what 'semantic' markup looks like. Short of well-executed microdata - I've always felt that a lot of claims about markup best-practice smacked of cargo-culting.
It's always worth asking the question: "semantic for whom"? i.e. who is the consumer. That clears away a lot of fog.
Looks rather neat, the bad thing is, that some kind of "inline" or "Medium-style" editing is not possible, as it seams (at least no example shows something like that).
I think, in some cases, text-input boxes are just looking awful.
Not sure what functionality you are talking about, but you can embed a Quill in any div. It doesn't have to have a border.
Where to put the toolbar? The medium editor has a toolbar that only appears when it is really needed.
Ah, another to satisfy our insatiable desire for browser-based, WYSYWIG text editors.
I've been using this on a project recently. I've had to modify its source to make it work in a Shadow DOM environment and it's been slow-going. The future is hard. :)
fill justify doesn't work.
Another rich text editor that doesn't enforce good typographic rules: You shouldn't underline text, except hyperlinks. Text shouldn't be both bold and italic. The text alignment of the body should be block or left (right instead of left in right aligned scripts).
Also no semantic information like what is a caption at all.
Why would the editor enforce those rules? Does Microsoft Word enforce those rules? Pages? Google Docs? This is a library that brings WYSIWYG editing to the web in a fairly clean way, and it shouldn't enforce any specific rules. If you want to enforce rules on your implementation, you can do so, but the library should be full featured and allow customization to have as much utility as possible.
Hmmmm. The defaults should be good. And some horrible things should maybe be off by default and strongly discouraged.
Underlining is a good example. It's a no-no on the web (looks too much like a hyperlink) and if your destination is print even then it's ugly and amateurish. I can't see it being too much of a stretch to just leave it out of an editor.
That should definitely be on the author using the WYSIWYG, not the editor being used.
All kidding aside, is there a genuine reason to name a development after an arcane, difficult to use tool? I've got a few quills. I used them as part of my graduate thesis on slowing down writing so that students can learn to appreciate the permanence of scribing down things. A quill is not a text editor, it's a one-shot, hard to use object. I'd like to be constructive in this criticism, so I'll sign off here.