Spark update: WYSIWYG choice

published on July 10, 2012

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!

Comments

Josh Miller's picture
Josh Miller

Exciting times, Wim. I love the Aloha Editor after visiting their site. I assume that since you are choosing “just one” you are not planning on abstracting the system so you could potentially choose a different one?

Wim Leers's picture
Wim Leers

We will definitely make sure that people can override the default WYSIWYG editor. But we also want to make sure the user/authoring experience is as good as possible as soon as you start using it, so we will ship with “just one”, without a built-in UI to choose a different one.

Alex Weber's picture

This is awesome news! Big props to the Spark team and everyone who chipped in for the great choice and to the Aloha Editor team for being open to the collaboration!

Christopher Pelham's picture

Congratulations! Will it support media module? Image module? The demos on the Aloha site seem to edit the text only.

Wim Leers's picture
Wim Leers

We want perfect support for image captions. Media module integration is also a high priority.

Lars Stadel Linnet's picture

I have had some bad experiences with Aloha in the past, but that was right after it was released - seems like it has really been improved and looks to actually be a good choice for Drupal, but I wonder if there have been throughs about embedding entities (like factbox nodes or file entities (images, videos etc)) directly into the current text from the Aloha editor?

Wim Leers's picture
Wim Leers

I’m not sure what it is precisely that you’re asking. Media module integration is a high priority, but I don’t think that fully answers your question?

S1L's picture

wow, I feel Spark is bringing Drupal to the next level. True in-place WYSIWYG editting, intuitive responsive layout creation. Wow.

dutch's picture

I’m confused by this choice. It seems the community discussion/testing on wysiwyg accessibility at http://drupal.org/node/1259750 (CKEditor vs TinyMCE) and even the Spark discussions pointed heavily towards CKEditor. Is there a review of accessibility for Aloha that I’m missing?

Wim Leers's picture
Wim Leers

No, you’re right, accessibility is an area we unfortunately have barely touched upon. The major reason for choosing Aloha is its solid core and feature completeness. That being said, their UI is currently changing with the move from ExtJS to jQuery UI. Furthermore, we’re going to roll a custom UI, so hopefully we’ll be able to ensure excellent accessibility that way.

Scromie's picture
Scromie

This is very exciting news. I see the potential of Aloha and am looking forward to it’s use, especially with images. Well done!

Wim Leers's picture
Wim Leers

There are some good things in there, but this is once again building pages, not structured content. In other words: PageCloud is basically Microsoft Frontpage on steroids.

That’s fine. It has its use cases. This is a simple brochureware site, and for such sites, that’s absolutely fine. But once there is a lot of content, that’s not workable.

Don’t get me wrong: PageCloud looks great — but it’s limited to simpler sites.

Of course, like always, I think Drupal can and should learn from this.

P.S.: fun to notice they also use CKEditor :)