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.
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.
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.
(It doesn't do much to compare/evaluate the options, but it's pretty up-to-date/comprehensive, which is a start)
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.
Are tables really hard to support? Every time I see one of these projects I check excitedly if they do but am always disappointed.
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.
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 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 and that handles the basic use cases extremely well while producing super clean output.
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.
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.
One interesting thing I found looking for table support a while back is that there is a medium-editor-handsontable extension. Something like this w/ the ability to attach a dedicated grid object (or embed a gdoc) is probably the way to go.
* super fast/responsive
* inline/contextual UI
* automatic transmogrification (s to ULs, ``` for code blocks, etc)
* revision tracking
* collaborative editing
* image uploads + formatting
* table insertion + editing
* task lists
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.
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.
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.
* 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.
<font color="#ff0000">hello, world</font>
It's always worth asking the question: "semantic for whom"? i.e. who is the consumer. That clears away a lot of fog.
I think, in some cases, text-input boxes are just looking awful.
Also no semantic information like what is a caption at all.
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.