Squire: FastMail’s rich text editor
blog.fastmail.com
blog.fastmail.com
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
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.
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.
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.
<xsl:include href="xsl/chart.xsl"/>
<xsl:include href="xsl/tags.xsl"/>
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!
<xsl:include href="xsl/chart.xsl"/>
<xsl:include href="xsl/tags.xsl"/>
<xsl:include href="chart.xsl"/>
<xsl:include href="tags.xsl"/>
https://greenbytes.de/tech/tc/xslt/
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.
As an aside, here's an interesting XSL file:
https://bitbucket.org/djarvis/world-politics/src/master/xml/...
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:
http://djarvis.bitbucket.org/xml/
Most places I've worked that employ XSLT use a different XSLT file for each (differing) XML document.
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).
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.
But in order to deal with browser inconsistencies and potential new and interesting features, the idea of WYSIWYM (What You See Is What You Mean) looks much more promising to me. The most important thing is, that the editor / workflows disallows users from making mistakes and get the result they wanted to. Regular WYSIWYG editors give too much freedom, resulting in mixed results and often confusion.
Even for simple tables, it's hard to edit a table if it has to look exactly like it should after editing. If you allow the editing experience to be different from the reading experience, you could provide additional hints and tools in the interface.
My personal experience is that often users prefer an even stricter way, of entering content through very strict and validating forms. The visual output can then be created from "raw" data. Which is not only consistent then, but can also be altered.
Of course there area areas where WYSIWYG is just fine, but then I'd prefer more "seamless" editors like http://www.aloha-editor.org/
For compatibility reasons I have to support a small fixed set of tags (b, s, u, tt basically) but of course none of the contenteditable commands use these tags, so I ended up using selection and range to insert the tags myself, and actively ignoring the browser's default shortcuts (ctrl-B, ctrl-I, etc automatically work in some browsers). The API for accessing selection is also different from that of simple input elements.
Now, I actually want pseudo-WYSIWYG - that is, I want bold text to be shown in bold, but I still want the <b> tag to be shown in light grey so you know it's there and you can edit it yourself. But people can also sometimes post just a "<" in their text, so basically at every keystroke the control has to parse the whole text again, insert whatever tags and apply whatever style might be necessary. Without forgetting the convert back to spaces the " "s the browser has helpfully included in the text.
Anyway, what I wanted to say is contenteditable is really not as usable as it could be, and there is a lack in pseudo-WYSIWYG libraries which just allow you to type your text using HTML (or markdown) tags and render them along with the final text. Thinking of it, maybe a more appropriate name for such a tool would be syntax-highlighting.
[0] https://github.com/seeschloss/miaoli/blob/master/public/java... (it's still a long way from being completely decorrelated from the main project, but I'd like to end up with a nice generic drop-in pseudo-wysiwyg control one day)
[1] http://sz.gy/tribune/test (don't be fooled by the fact that it has a domain name, it's far from production ready - also, the control doesn't work well with mobile Safari, for some reason I don't understand yet)
Also check out Scribe - https://github.com/guardian/scribe which is similarly very light weight - has no UI built in. Mostly exists to fix browser inconsistencies with contenteditable.
Squire (don't know if the similar naming is by co-incidence) and it's one 10KB file seems very appealing.
/happy Fastmail customer
Excited to look at the source code for squire as an example!
hooray open source.
The handling of bulleted lists seems a bit more robust but that may be I've just been trained out of my bad habits.
(I've got a couple more to write myself as well - but while I've managed to get other people writing, I'm going to sit on mine for a bit and save them for a day when I don't have anything else to use. It's a surprisingly large amount of work putting together a detailed blog post every day, and I really only even thought of doing it a couple of days before we had to start)
I'm still on the train on the way to work - my wife starts work earlier than I do, so I have to get the kids to school first. I pinged the rest of the team over IRC, and they added:
"we don't have any trade secrets. email isn't unknown, just complex. if you have a team of appropriately skilled people you can do it too, but if you have a team of appropriately skilled people you're probably going to do something less painful"
The thing is, it is actually pretty hard. I got paged in the middle of the night a couple of days ago when our forwarding IP got listed on ips.backscatterers.org. We watch a ton of blocklists to make sure our outbound IPs are clean, so legitimate email doesn't get blocked. In this case it was a forwarding account, and they said "check your logs at this timestamp plus or minus a minute, it will be obvoious which email caused you to get listed". Yeah, right. There were thousands of emails within those couple of minutes - it's OK if you send 5 emails per day. The only option would be to lock the user who was the cause of the report through innocently reporting an email that was forwarded through a FastMail alias. So we had to stop checking that blocklist.
We deal with stolen accounts _every_day_. We deal with hacking attempts, DOS attacks, weird crap like Optus/Vodafone mobile networks in Australia being unable to access us for a few hours because of a fault in Singtel's network for packets going _back_ from New York. Nothing we, or even our datacentre could fix - but of course most of our customers don't know, they just want their email, and it's not working. Most of the other sites those customers access are in Australia or at least US West Coast, so it looks like it's just us that's down.
So yeah, if somebody reads our blog posts and decides that running an email service is for them, good luck to them I say. I welcome their contributions to the Open Source projects I work on :)
On the other hand, I am not sure it is overly naive to assume that if your data is not in the US, it's safe. The primary rational motive would be to show with your wallet that hoarding data is not appreciated.
If you press "b" then go back to typing, the output is not bold. To bold text you have to select previously typed text and then apply the styling.
I don't think this would be intuitive to most users.
We need better WYSIWYG-API implementations for HTML5. Sure, it would mean competition to web office apps from Microsoft, Apple and Google. A Word-clone web app could be a single HTML5 code line, but at the moment due to the broken API e.g. Google Docs renders the page line by line as seperate divs, even the blinking cursur is a div - it's a complex full page render engine based on divs!! And no similar open source project exists.
Check out http://quilljs.com -- it's a cross browser rich text editor that does provide such an api.
Granted, it doesn't yet have all the functionality of a complete word processor, but it's early days and its module system provides good extensibility. Part of what's exciting to me about it is that it's also a good chance to rethink what a word processor should provide in the context of the web, instead of simply porting what made sense when the target was printing a document to paper.