Fair enough. It takes a lot of time to: voluntarily find and download each editor, see how well (and easily) they integrate with the sample page, and perform the basic research. I readily admit that mistakes may have been made.
In addition to injecting superfluous markup, Quill also changes the font.
Incidentally, the LICENSE file does not explicitly state that it is BSD-based. I admit that I did not read (very far) below the fold on either the Quill homepage or its Github page, but went directly to the LICENSE file. (Again, mostly because I don't want to waste a lot of time hunting for the same information across 30+ projects.)
As far as I have discovered, no other such comprehensive comparison exists. I trust readers will verify the information for themselves and hope that it may prove useful.
The sample page (http://djarvis.bitbucket.org/xml/support.xml) is in XML which is an input Quill and many other WYSIWYG editors do not support (nor claim to). Right now Chrome will not even render this page.
Yet another unfortunate difference in browser implementations. Firefox can use relative paths in XSL includes, whereas Chrome cannot find files included using (for example):
Should work now. To clarify, the XML page is first transformed using the browser's internal XSLT engine. This produces a standard HTML DOM. The browser passes that HTML DOM to its HTML rendering pipeline. The JavaScript and CSS operate no differently on an XML-transformed-HTML page than they would a static HTML file.
So you just fixed the issue? What was the problem causing the mis-render? Thanks for starting the project I think the basic premise of using the browser for selection & apply transforms manually is superb idea, possibly the only one that can work consistently in the current messy environment!
I wouldn't recommend using client-side XSLT, though, for anything other than a quick proof-of-concept. There are technical differences that can create problems:
The nice idea about client-side XSLT is that you can push the files to servers where you don't have server-side access, and still render the page. Once the XSLT is written, it's relatively easy to migrate to a server-side solution. Using a server-based XSL transformer then removes the headaches associated with client-side XSLT engine differences.
It transforms any simple XML document (i.e., attribute-free) into a similarly DIV-nested HTML document. The result is that all the pages in the following web site use a single transformation combined with corresponding CSS files:
Looks like a standard 3-clause BSD license to me. It's short enough that you can read through it in less than a minute, and know whether you want to use it or not.
And if I read all the licenses for all the software, there goes an hour that I never get back. It's not about me using the software--please see the link I posted above: I'm voluntarily documenting the current state of this calamitous cacophony of cross-browser editors. (Eventually I want to choose one for an app, but I want it to be an editor that works and meets the criteria in the aforementioned link.)
FWIW, here are two pictures of the same page:
- http://i.imgur.com/CThwDev.png (Quill)
- http://i.imgur.com/FXiVmBd.png (Aloha)
In addition to injecting superfluous markup, Quill also changes the font.
Incidentally, the LICENSE file does not explicitly state that it is BSD-based. I admit that I did not read (very far) below the fold on either the Quill homepage or its Github page, but went directly to the LICENSE file. (Again, mostly because I don't want to waste a lot of time hunting for the same information across 30+ projects.)
https://github.com/quilljs/quill/blob/develop/LICENSE
As far as I have discovered, no other such comprehensive comparison exists. I trust readers will verify the information for themselves and hope that it may prove useful.