The real reason contentEditable doesn’t have a future
Text editing remains one of the most important but least improved features in modern software.
Users’ expectations of software for writing on the web are still defined by Microsoft Word, a 30-year-old juggernaut that was designed in an era when the ‘paperless office’ was still a fantasy.
From a technical perspective, things aren’t much better. Current solutions for writing on the web remain dominated by contentEditable: the HTML attribute that lets users edit the content of an element. contentEditable forms the basis of most web-based text editors.
Fundamentally, though, contentEditable isn’t fit for purpose. It was designed to turn browsers into WYSIWYG HTML editors, but it turns out that this is not a job for the browser.
The problem with contentEditable 101
The good news is that there are many smart people chipping away at this problem. There are some brilliant explanations of why contentEditable is no longer fit for purpose. Here’s the simple version:
Different browsers generate HTML in contentEditable elements differently. The WYSIWYG view might look the same to the end user, but the underlying HTML is different.
Take this example: the HTML which displays “Bold and italic” could be represented in the following different ways:
<strong><em>Bold and italic</em></strong>
<em><strong>Bold and italic</strong></em>
<em><strong>Bold and</strong><strong>italic</strong></em>
<b><i>Bold and italic</i></b>
<b><em>Bold and italic</em></b>
And so on and so forth. This is the simplest possible case — real world scenarios are often much more complicated.
From a users’ perspective, if you’ve ever copied and pasted text from one editor to another and found the resulting formatting to be unexpectedly different, you have contentEditable to thank.
However, despite more discussion about the failings of contentEditable, there is a fundamental problem that is still being over-looked: the problem of how you support collaboration on text.
Why collaboration matters far more than you think
The ability to work in realtime with another person on anything on the web will become a basic user expectation of all web-based software — and that change is going to happen soon.
We will look back to 2015 as the days when it was still just about acceptable to email a file around in order for someone to make a contribution to it and send it back as a hilarious dark age where we all wasted our time shouting past one another. Google Docs is the Nokia 3310 of collaborative productivity tools.
The ability for two or more people to access, discuss and make changes to content simultaneously will become as normal and expected by users as the ability to add a string of smilie-faced emoji to a text message is right now.
Not only will users come to expect this behaviour, but this is a Good Thing. We’ll waste less time, be less annoying to our colleagues, express ourselves more clearly and be more transparent about our creative — and not so creative — processes.
As we’re thinking about the future of writing on the web, if we neglect the need for people to collaborate together, we’re missing a huge trick.
We can’t let that happen.
Why contentEditable and collaboration are incompatible
At its core, the problem of managing user collaboration is one of version control: we need to know who changed what and when. We also need to display those changes to the user in a simple, understandable way. The problem of collaboration is one that can only be solved by carefully balancing technology and design.
Let’s go back to our simple example:
<strong><em>Bold and italic</em></strong>
Say you wanted to add the letters ‘er’ after ‘Bold’. But your colleague wants to replace the word ‘and’ with ‘or’ at the same time.
How software manages the above scenario — merging those changes without conflicts and producing the outcome expected by both users i.e. “Bolder or italic” — is the basic problem collaborative software has to solve.
The problem for contentEditable is that in order to know who’s changed what and when, the browsers have to have the same understanding of what’s being changed:
<strong><em>Bold and italic</em></strong>
<b><i>Bold and italic</i></b>
Without getting into too much detail, building a collaborative system that can reliably understand that the abstract meaning of the two strings above are the same is an immense problem. It might be impossible in practice, since what we’re talking about is really interpreting different browsers’ models for text. Instead, the best approach is to deal simply with text, and treat any formatting separately.
This circle can’t be squared: contentEditable’s approach to editing text makes building collaborative products harder than it would be otherwise. We can’t mix an abstract HTML representation of text and the text itself; they need to be separate.
Building sustainable standards
At Poetica, we care about these problems immensely. We care about building great products users love and we care about the future of the web.
We’re really excited that there are more and more smart people recognising the huge opportunity in re-thinking the most fundamental of our freedoms that the web has afforded us — the ability to write and publish whatever’s on our minds.
But if we miss the role of realtime collaboration in this future, we’ll not only be having this conversation again far sooner than we’d like, but we’ll be building poor-quality tools for users who will demand more.
Further reading:
The road to HTML 5: contentEditable
Why ContentEditable is Terrible
Originally published at blog.poetica.com on October 29, 2015.
