Thoughts on the future of web-based HTML editors

The ability of editing HTML content on the web is nothing new, we’ve all used it to write emails in Web-based email clients, post content on our blogs, adding content to web sites, etc.  Web sites usually do this using the execCommand API, with either iframes put into designMode, or contentEditable elements, and occasionally utilize things such as the DOM Range API and Selection API.

Things sound great, but in practice, they’re not.  If you’re a web developer, you know that almost nobody tries to use the above APIs directly, and instead everyone resorts to one of the web editor widgets.  The reason for that in my opinion is that there are numerous problems with how browsers implement HTML editing, and these problems cause real pain for web developers, and make it extremely tricky, if possible at all, to get a cross browser and interoperable HTML editing experience.  So, let’s see where the problem lies.

  • Problems with the API.  The execCommand API was first added to IE 5.5 by Microsoft.  This API is very different to all other web APIs, and is in fact an adaptation of the IOleCommandTarget API in MSCOM.  This API is very hard to use, because:
    • It is unintuitive: you just issue commands, and you can’t even control where the commands are going to end up affecting directly.
    • It is not extensible: you don’t have any way to add your own editing commands in a seamless way.  You can’t even query the browser to determine which sets of commands it supports.
    • It is not customizable: some of the commands might show a user interface component provided by the browser, and there is no way to disable that UI or change how it looks.
    • It is not comprehensive: some very important editing functions (like undo/redo lists and spell-checking) are not exposed via the API at all, so there is no way to integrate them into your web application.  You can’t even be sure that those built-in facilities will even work if you’re not careful enough (example: modifying the editable DOM tree in some browsers disables undo/redo functionality.)
  • Lack of specification.  Because web based editing was first added as a proprietary feature to IE, there is no specification defining how it should work.  Other browsers tried to come up with a compatible set of APIs, but that’s unfortunately not even possible, because nobody really knows how IE works in every aspect, so nobody can aim to emulate its behavior correctly.  The lack of specification has created several real-world problems for both web developers and users:
    • Nobody knows what should happen after a command.  For example, when you issue a bold command, some browsers choose to wrap the selected text in a <b> tag, some use a <strong> tag, and some use CSS styles on a <span> element (and there are many more cases for what can happen when a bold command is issued.  This means that if you issue a set of editing commands in different browsers, the HTML markup generated can vary greatly.
    • Nobody knows how (and if) interoperability should happen.  Let’s take the example of the bold command here.  Because different browsers tend to use different methods to make text bold, they usually have difficulty removing the bold style from some piece of text.  This is really frustrating for users, and there is no easy solution to this problem.
    • Nobody knows how keyboard commands should affect the editable area.  Pressing a key can have multiple results based on the position of selection/caret.  For example, pressing Enter can lead to text being deleted, injected, elements being deleted, injected, and it can modify the caret position in unexpected ways.
    • The default behavior of keyboard shortcuts are not specified.   For example, web browsers may choose to tie Ctrl/Cmd+B to the Bold command, but it’s not possible for web pages to determine what these keyboard shortcuts do, and if they are even available (they might not be on localized versions of browsers, for example.)
    • Nobody knows how the browser should handle HTML data from external sources (such as pasting something inside the editor, or setting the innerHTML attribute.)
  • Poor quality of implementation.  Implementing an HTML editor can be extremely complex.  And it turns out that you can actually find bugs with all of the major browsers by just playing with a content editable element for a few minutes!

As you can see, the situation is not very good here.  We have some API which has a lot of problems in its own, and every browser has tried to implement it to some extent, but the behavior of each browser is different, and there is no specification which determines how a browser should implement this functionality.  What this means in practice for web developers is that getting a cross-browser web application which uses these APIs directly is extremely difficult to achieve, and that is why web developers prefer to use web editor widgets which have tried to abstract away as much of these problems as possible.

There have been some attempts at trying to add a common denominator of what different browsers do today into the HTML5 specification, but we need more comprehensive specification to be able to address all of the existing issues.

Mozilla has recently launched a mailing list for people interested in the current state and future of HTML editing in web browsers.  The list is called htmlediting-community.  We are looking for web developers, engineers working on browser engines, people interested in web based APIs and the future of HTML editing to join to this list, so that we can discuss the current issues with HTML editing in web browsers, and where we should be headed in terms of improvements to the web-based HTML editing experience for both users and developers.  Subscribe to this list here!

I’ve recently started to work on Mozilla’s HTML editor implementation (which is called Midas).  I have some plans on how to attack the above problems from different aspects.  Some of the plans are laid out as the following.

  • Fixing some problems which are relatively easy to fix in the near future.  I think we should have both a short and long term plan, and we should try to make some improvements, especially those which can help web developers and users a lot.  I’m looking for feedback from web developers on what those issues are, so that I can come up with a list of things to fix hopefully for the next release of Firefox.
  • Trying to create a comprehensive specification which can be used to implement HTML editing consistently across browsers and platforms.  This specification should address the currently existing APIs and user interactions, and should also propose a new set of APIs which don’t suffer from the basic problems I described above.  The new APIs should be extensible, customizable, intuitive and comprehensive.
  • Trying to write a set of cross-browser unit tests which can be used to test the implementation of both the existing and new APIs in different browsers.  The very important thing here is for the tests to work on multiple browsers, because I want the result of this work to be useful for other browser engines as well, so that we can all help move the web forward by providing a better HTML editing experience across browsers.  I’ve decided that I would try to extend the current BrowserScope RichText tests, so that we can use that work inside Mozilla and hopefully other browsers.
  • Trying to look into the best approach to move the HTML editor component for Mozilla forward.  At this point, I believe that rewriting the HTML editing support in JavaScript might be the best path to take here, because the existing code is extremely complex and fragile, and is not very well understood.  Also, implement this in JavaScript could have a few advantages, like making the less likely to cause crashes, more readable, and cleaner.  And maybe at some point we can actually consider taking the Mozilla-specific code and rewriting it for other web engines so that we can make the same code work in other browsers!

I’m still trying to figure out what needs to be done exactly in each part, and how to best tackle the problems.  I’d very much like to hear what the web has to say here.  If you’re a web developer, web browser engineer, or even a simple user, please leave comments and share what you think.  I will be writing more about this topic as I give it more thoughts, so you can keep an eye on the related posts in the future.  Oh, and participation on the htmlediting-community mailing list is very much appreciated as well!

Posted in Blog Tagged with: , ,
31 comments on “Thoughts on the future of web-based HTML editors
  1. Having discovered 11 security-critical memory safety bugs in editor code, I’m thrilled that you’re considering tossing out all that C++ and replacing it with JavaScript.

  2. I am very interested, particularly in re-implementing the contenteditable behaviour in JavaScript. The current implementation causes too many problems … particularly when text is created in one browser and edited in another.

  3. […] Thoughts on the future of web-based HTML editors | Ehsan Akhgari Share and […]

  4. […] the original post: Thoughts on the future of web-based HTML editors | Ehsan Akhgari Share and […]

  5. It will be really very interesting to see the future web based Html.

  6. Ehsan Akhgari says:

    I hear your pain.  I think this is a good direction for us to move towards generally, to minimize the risk of security bugs which are mainly a result of the programming language used to write the code.

  7. Ehsan Akhgari says:

    Thanks for your enthusiasm!

    Please join the mailing list, as we need to have a lot of voices in the initial stages to make sure that we don’t make the same mistakes in another form in the early phases of the project.

  8. skierpage says:

    Is Midas the same code as the HTML editor that’s in Thunderbird and SeaMonkey, that I hope will some day be improved by https://bugzilla.mozilla.org/show_bug.cgi?id=477840 (“Backport KompoZer to Composer”)?

    I think not because Midas seems mostly implemented by nsHTMLDocument.cpp and the fancy table support and such of Thunderbird is in a separate big editor/composer directory, but it’s confusing.

    I found two informative demos: http://www.mozilla.org/editor/midasdemo/ uses designmode and no contenteditable and creates a simple toolbar that invokes a lot of execCommand; http://html5demos.com/contenteditable has a contenteditable section but still sets designmode, and doesn’t use execCommand (maybe because it doesn’t do much).

  9. pd says:

    Finally someone covers this topic again.

    I have been trying to get this topic some attention for years. It astounds me that people talk about the web as some sort of read/write tool when there is no such thing as a decent richtextarea just the crappy old textarea.

    HTML5? Useless unless it addresses this major hole in the web. It is incredible that browser vendors go off creating all sorts of graphic-card acceleration, SVG, canvas, JS threading … you name it … yet HTML still cannot perform the basic tasks of the average craptacular desktop text editor like Wordpad.

    Please can someone take this article as a starting point and get a richtextarea tag into HTML5 or 6 as an alternative to textarea?!

  10. Ehsan Akhgari says:

    We will definitely try to submit our specification to be included in HTML5.  Before we do that, though, we should come up with a decent specification, and that’s where you can help a lot!  Please join the mailing list and voice your opinion in the future discussions happening there.  Your feedback is really appreciated!

  11. Ehsan Akhgari says:

    Midas is the underlying HTML editor engine.  The contenteditable elements in Mozilla-based applications are based on it.  Thunderbird also uses it for editing messages.  SeaMonkey uses it to build a desktop HTML editor application (KompoZer is a bug-fix release of the stand-alone editor application in SeaMonkey which is called Composer.)

    The demos you mentioned are both web demos, and that’s what I care about the most, but any work done in this area can also be useful to applications such as Thunderbird, SeaMonkey or KompoZer as well.

  12. You might want to get in contact with Fabien from KompoZer as well, as we’re trying to tie in his work into SeaMonkey/comm-central in the 1.9.3 timeframe, and he might have some patches against mozilla-central as well that he might want to land or work on.

  13. pd says:

    I’ve joined the mailing list, even though I really hate mailing lists as a form of communication 🙂

    Haven’t seen any traffic on it yet. Maybe I could start some.

  14. Ehsan Akhgari says:

    I’ve been waiting for more people to sign up.  I think I’ll start the first discussion early next week.  Feel free to start any discussion in the interim, though!