Spark update: WYSIWYG choice

A few weeks ago, we showed the in-line editing prototype we had built for Spark, which has now blossomed into Edit module. Additionally, we also pointed out that we were in the process of selecting the WYSIWYG editor to use in Spark. This selection process was performed in the public Spark issue queue, in order to gather community feedback and to attempt to reach consensus. 73 people followed that issue, about two dozen of whom contributed to the discussion as well.

Spark has a well-defined goal for its choice in WYSIWYG editor: we want authors to be able edit content directly on the page while it has the exact same styling that it will have when it is being viewed by a site visitor, also known as “true WYSIWYG.” However, Spark’s WYSIWYG editor also needs to support a more “traditional” WYSIWYG model which injects the editor into a textarea form field, such as on the node add/edit form. We want to use Aloha Editor for in-line editing, but also on the back-end — I think nobody is looking forward to having to use two WYSIWYG editors. On the back-end, it of course can’t be “true WYSIWYG”, it will be “structural WYSIWYG”.

Today, we’d like to share our WYSIWYG editor choice for Spark: Aloha Editor. After several feedback rounds from the community in the aforementioned issue, the consensus started gravitating towards Aloha. We then had a call with Aloha’s development team that answered many of the community’s questions and concerns. They have even offered to host a sprint in their offices in Vienna in mid-July for key members of the Spark and Drupal community to collaborate with their development team on making Aloha Editor integrate more cleanly with Drupal.

Aloha Editor is definitely not perfect, and to correct the biggest problems (most notably: its sheer size), the Aloha team currently have some major changes underway — much like Drupal. The biggest change is a move to jQuery UI from ExtJS, which will drop the code base size considerably. Next they plan to make sure it’s possible to not load the additional JavaScript that is needed for compatibility reasons only. This means that e.g. Google Chrome users will need to load far less data. As the internet population moves on to newer and better browsers, we’ll need to load fewer files!

Despite not being as mature an editor as some other contenders such as TinyMCE or CKEditor, Aloha Editor does have much going for it. It has solid cross-browser support (including IE8), a very complete feature set, great support for pasting from Word, RTL support, a proven plug-in system, the ability to completely override the UI, an abstraction for dealing with “islands of content” inside textual content for e.g. image captions, media and tokens (Aloha Blocks — this is what shows the flexibility of their plug-in system), unit tests, and asynchronous loading (they use RequireJS) for performance.

If you’d like to learn more about Aloha Editor, or have questions or criticism, please see the two aforementioned issues. The issue summaries should guide you to the information you’re looking for.

Soon, we’ll start working on integrating Aloha Editor with Drupal in Spark. Keep an eye on the Edit module and Spark distribution project pages!