

Squire: FastMail’s rich text editor - brongondwana
http://blog.fastmail.com/2014/12/08/squire-fastmails-rich-text-editor/

======
thangalin
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
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
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.

~~~
jhchen
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
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.

~~~
dingdingdang
> Should work now.

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!

~~~
thangalin
This works fine in Firefox, but not Chrome:

    
    
        <xsl:include href="xsl/chart.xsl"/>
        <xsl:include href="xsl/tags.xsl"/>
    

To work in both Firefox and Chrome, all the XSL files need to be moved into
the same directory and referenced without a relative path:

    
    
        <xsl:include href="chart.xsl"/>
        <xsl:include href="tags.xsl"/>
    

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:

[https://greenbytes.de/tech/tc/xslt/](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/...](https://bitbucket.org/djarvis/world-
politics/src/master/xml/common.xsl)

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/](http://djarvis.bitbucket.org/xml/)

Most places I've worked that employ XSLT use a different XSLT file for each
(differing) XML document.

------
Fannon
The more I think about it, I dislike the idea of WYSIWYG editors. Not that I
would force normal users into writing markup, thats even worse.

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/](http://www.aloha-
editor.org/)

------
seszett
I have been experimenting with contenteditable myself[0] (for a small instant
messaging project [1]), and indeed I found it quite difficult to use. The
problem is you're constantly going to be doing things _against_ the browser.

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
"&nbsp;"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...](https://github.com/seeschloss/miaoli/blob/master/public/javascripts/puli.js)
(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](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)

~~~
zackham
Might give
[https://github.com/codemirror/codemirror](https://github.com/codemirror/codemirror)
a try if you really want to go down the syntax highlighting path. Shouldn't be
too hard to adapt it to exactly what you're looking to do.

~~~
seszett
It seems a bit like overkill for my simple needs though, while at the same
time it would require me to write a custom "mode", so I'm not sure that would
be the best option.

------
sqren
Direct link to the demo:
[http://neilj.github.io/Squire/](http://neilj.github.io/Squire/)

------
philfreo
Thanks for releasing! It would be awesome to see your toolbar / UI released as
a separate project also.

Also check out Scribe -
[https://github.com/guardian/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.

~~~
aroman
Given they linked to that repo from the article, I think it's safe to say
they've seen it. :-)

~~~
philfreo
That was intended for everyone else reading this :). Plus they only linked to
one readme file rather than scribe's homepage.

------
misiti3780
Unless I am missing something - it looks like quill.js still has more
features:

[http://quilljs.com/](http://quilljs.com/)

~~~
thelibrarian
Quill is a web content editor, and Squire is an email editor. They are very
similar, but slightly different - e.g. Squire supports quoting and changing
quote levels, and knows how to handle attachments.

~~~
timhaines
I went looking for where their docs talk about handling attachments, and
couldn't find it. Can you point me in the right direction?

~~~
robn_fastmail
Not sure what's about either. Like many rich-text editors, it can handle
embedded images, but the attachment stuff proper is handled in the surrounding
application.

~~~
thelibrarian
My mistake - I was editing an email at the time, and looking at the editor and
roving over the UI, I thought "attachments, of course!", without actually
checking to see whether or not that was part of the editor or not.

------
frik
It has some glitches on iOS.

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.

~~~
byronm
> And no similar open source project exists.

Check out [http://quilljs.com](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.

------
mrschwabe
Looking forward to comparing this vs Scribe by the Guardian! Which is already
a very good, somewhat lightweight HTML text editor. I say 'somewhat' because I
find the installation and their plugin architecture rather clunky.

Squire (don't know if the similar naming is by co-incidence) and it's one 10KB
file seems very appealing.

/happy Fastmail customer

------
jrochkind1
I wanted to do something with JS range and selection API's, but was having
trouble figuring out how they worked or what browser support they actually
have.

Excited to look at the source code for squire as an example!

hooray open source.

------
anilshanbhag
I personally like Readactor. It is light weight and cross-browser. After using
it in an app which started to make money, I finally paid up for the premium
and it was worth it.

------
sandwell
Happy FastMail customer, but sometimes the editor is buggy (cursor appears in
the middle of text when editing and jumps around a lot making it difficult to
type), which is not something I've noticed with other editors like CK or
TinyMce. I wonder if that is an artifact of the DIY approach rather than
delegating to the browser.

~~~
nmjenkins
If you have a way of reproducing this, please file a support ticket. We've not
come across this issue so far. Thanks.

~~~
sandwell
Will do, it's been a quiet day so far though :)

------
ChuckMcM
Interesting. It still has issues with the "oops I have too many words in the
selection that I made into a link and I want to fix it." This is a problem in
Gmail's editor as well.

The handling of bulleted lists seems a bit more robust but that may be I've
just been trained out of my bad habits.

------
nchelluri
I'm turning into a fan of this article series. Maybe I will become a customer
at some point.

~~~
sandstrom
I hope the next post in their series will be on opening a DC in Iceland, for
non-US email storage.

~~~
brongondwana
We've still got Confidentiality and Availability to go in the security series
:)

(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)

~~~
trop
Question for brongondwana: was there a discussion about how much to reveal
about Fastmail's inner workings? That is, when do articles moves from
discussing best practices (and already open source code) and into revealing
trade secrets of running a top-quality email service?

~~~
brongondwana
My response was this: Honestly, there's not that much that is a trade secret
about how we operate. We're not running at such high margins that there's a
big opportunity for somebody to take what they learn from these blog posts and
build a cheaper service to undercut us.

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 :)

~~~
trop
Thank you! That's great to see it laid out that way. Wonderful (at least from
the point of view of someone not having to solve all these situations) to see
email described as a problem which requires such continual and skilled care. I
guess it's still a problem which scales (witness all the FastMail subscribers,
myself included), but may not be the model YC-style business, at least as it
currently stands?

------
eterm
I don't like how it (doesn't) handle toggling bold etc.

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.

~~~
matthewborden
@eterm Feel free to submit a pull request and implement it. Here's the link to
the demo source: [https://github.com/neilj/Squire/tree/Squire-
UI](https://github.com/neilj/Squire/tree/Squire-UI)

------
glass-
I have been with Fastmail for a few years now and I don't think I have ever
used the rich text editor, only plain text. I wonder how common that is.

------
Animats
I'd settle for Thunderbird wrapping lines correctly.

