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.

The playground favors very short code for experimentation, given the limited screen real estate for the split view.

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/

Thanks for your reply. I think the quill.core.js option addresses both of these issues.

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:

    <section>
      <h1>First Section</h1>
      <p>Text...</p>
      <p>Text...</p>
    </section>

    <section>
      <h1>Second Section</h1>
      <p>Text...</p>
      <p>Text...</p>
    </section>

[1] https://github.com/quilljs/parchment#block-blot

You can use a container blot, which is how lists are implemented. A container blot represents <ol> and a block blot represents <li>.

Congratulations for this project!

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'm sorry you are experiencing problems on your device/browser but I don't think it's fair to say Quill does not take mobile browsers into account.

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.

It's very difficult to make a fully working browser/webview based editor on Android. Every keyboard interacts with applications differently, sometimes differing significantly between keyboard versions. I think a rewrite of the Android keyboard composition interface is needed. Most of the issues occur because the keyboard needs to keep track of the document state itself, and has race conditions/inconsistencies with the editable which maintains the "true" state.

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.

I confirm, it is my keyboard (Swifkey) who creates those issues, it works smoothly with the default one. Thank you for your explanations and sorry if my feedback was a bit harsh :)

Great job -- nice work!

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?

Sure, the Playground default now has code blocks in the toolbar.

Awesome - thank you!

Looks great! BTW the link to the LaTEX example is 404ing.

Thanks and fixed!

dear jhchen, the name quill nearly same to quill from quintic. I'm ain't from quintic ya.