4 ms·

There's a deeper issue here that needs to be addressed. Consider the following review: https://bitbucket.org/djarvis/world-politics/wiki/Editor https://bitbuck

There's a deeper issue here that needs to be addressed. Consider the following review: https://bitbucket.org/djarvis/world-politics/wiki/Editor https://bitbucket.org/djarvis/world-politics/wiki/Editor There are well over 30 WYSIWYG editors that (fail to) normalize the differences between browsers to provide a consistent text editing experience. Much of this duplicated effort would be better directed at reviewing, publishing, and updating a standard draft for editable, browser-based content. https://blog.whatwg.org/the-road-to-html-5-contenteditable https://blog.whatwg.org/the-road-to-html-5-contenteditable Even though Squire isn't meant as a drop-in replacement for web page editing, it still suffers from the same endemic issue that plagues all editors: browser inconsistency.

jhchen 12y ago
One of Quill’s goals is to be a browser consistent editor. It already produces identical HTML between browsers and everything runs through an automated test suite covering over a dozen platforms. I wouldn’t say it has succeeded in this regard yet (it’s still pre-1.0 software) but it’s at least a goal. Perhaps Quill will be the first to achieve this but I do think many other new editors are hot on the heels. The problematic ones are very old editors and too lightweight of editors (it’s not possible to solve all of contenteditable’s issues in ten lines of code). I’m not sure where Squire falls but it’s always interesting to see different approaches and use cases. I hate to be nitpick, but since the linked editor list has ~10 facts per editor, and at least two of them are incorrect about Quill (Quill does not depend on jQuery and its license is BSD. Also unclear about the wrapping complaint), I have to say I’m not sure it’s a very reliable list. Disclaimer: I am the author and maintainer of Quill.
- thangalin 12y ago
  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. FWIW, here are two pictures of the same page: - http://i.imgur.com/CThwDev.png http://i.imgur.com/CThwDev.png (Quill) - http://i.imgur.com/FXiVmBd.png 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 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.
  - X-Istence 12y ago
    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.
    - thangalin 12y ago
      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.)
      - X-Istence 12y ago
        If the LICENSE is important to you (and it is to me when I choose to build software on top of existing libraries) you should take the time to read it.
  - jhchen 12y ago
    The sample page (http://djarvis.bitbucket.org/xml/support.xml 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.
    - thangalin 12y ago
      Yet another unfortunate difference in browser implementations. Firefox can use relative paths in XSL includes, whereas Chrome cannot find files included using (for example): <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> 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.
robn_fastmail 12y ago
> Even though Squire isn't meant as a drop-in replacement for web page editing, it still suffers from the same endemic issue that plagues all editors: browser inconsistency. Squire's purpose is to make things look on-screen and in email the way the user expects it to look. The actual HTML generated is secondary to that. While its nice if it can produce the same HTML every time on every browser, its not especially important. In terms of UI consistency, its intention is to provide a simple, pleasant editing environment that the user is mostly familiar with it (keyboard controls etc). Again, it doesn't have to be identical everywhere, as long as it does what the user expects. (Note: I'm a FastMail employee, but not directly involved with Squire).
- dingdingdang 12y ago
  > Squire's purpose is to make things look on-screen and in email the way the user expects it to look. The actual HTML generated is secondary to that. How on earth does that work? Seems completely self-contradicting to me - it is exactly the generated HTML markup that needs to stay consistent in order for one to have a chance of normalizing the viewport through CSS?! Would really like to hear one of the Squire maintainers input on this. Thanks for taking part in the discussion btw.

jhchen 12y ago

One of Quill’s goals is to be a browser consistent editor. It already produces identical HTML between browsers and everything runs through an automated test suite covering over a dozen platforms. I wouldn’t say it has succeeded in this regard yet (it’s still pre-1.0 software) but it’s at least a goal. Perhaps Quill will be the first to achieve this but I do think many other new editors are hot on the heels. The problematic ones are very old editors and too lightweight of editors (it’s not possible to solve all of contenteditable’s issues in ten lines of code). I’m not sure where Squire falls but it’s always interesting to see different approaches and use cases. I hate to be nitpick, but since the linked editor list has ~10 facts per editor, and at least two of them are incorrect about Quill (Quill does not depend on jQuery and its license is BSD. Also unclear about the wrapping complaint), I have to say I’m not sure it’s a very reliable list. Disclaimer: I am the author and maintainer of Quill.

thangalin 12y ago
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. FWIW, here are two pictures of the same page: - http://i.imgur.com/CThwDev.png http://i.imgur.com/CThwDev.png (Quill) - http://i.imgur.com/FXiVmBd.png 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 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.
- X-Istence 12y ago
  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.
  - thangalin 12y ago
    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.)
    - X-Istence 12y ago
      If the LICENSE is important to you (and it is to me when I choose to build software on top of existing libraries) you should take the time to read it.
- jhchen 12y ago
  The sample page (http://djarvis.bitbucket.org/xml/support.xml 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.
  - thangalin 12y ago
    Yet another unfortunate difference in browser implementations. Firefox can use relative paths in XSL includes, whereas Chrome cannot find files included using (for example): <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> 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.

robn_fastmail 12y ago

> Even though Squire isn't meant as a drop-in replacement for web page editing, it still suffers from the same endemic issue that plagues all editors: browser inconsistency. Squire's purpose is to make things look on-screen and in email the way the user expects it to look. The actual HTML generated is secondary to that. While its nice if it can produce the same HTML every time on every browser, its not especially important. In terms of UI consistency, its intention is to provide a simple, pleasant editing environment that the user is mostly familiar with it (keyboard controls etc). Again, it doesn't have to be identical everywhere, as long as it does what the user expects. (Note: I'm a FastMail employee, but not directly involved with Squire).

dingdingdang 12y ago
> Squire's purpose is to make things look on-screen and in email the way the user expects it to look. The actual HTML generated is secondary to that. How on earth does that work? Seems completely self-contradicting to me - it is exactly the generated HTML markup that needs to stay consistent in order for one to have a chance of normalizing the viewport through CSS?! Would really like to hear one of the Squire maintainers input on this. Thanks for taking part in the discussion btw.