With Aloha's community support growing in #1580210: Figure out what WYSIWYG editor to use, we — Théodore "nod_" Biadala, Nate "quicksketch" Haug and I — had a technical call yesterday with the Aloha Editor developers, to figure out whether Aloha Editor really is a good match for Drupal.

There's a Google Doc (everybody can comment, not edit) with lots of notes and a bunch of links.

Highlights:

  • Input filters: tokens/media.module/…, but also images/image alignment/image captions: we should use Aloha Blocks for this. Aloha Blocks requires DOM nodes to function, so upon editing, "[site:name]" should not be rendered as "drupal.org", but as e.g. "<span class="some-class" data-token="[site:name]">drupal.org</span>". The point: we'll need well-defined transformations to support this, but it seems doable. This is already being discussed at #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up.
    Overall, it seems this would work pretty well.
  • Flexibility: Can Aloha plug-ins let us do everything we need to do? Hard to answer conclusively, but it definitely is very flexible. Aloha Blocks, for example, is just another Aloha plug-in.
  • Security/pasting from Word: extensive filter system. Pasting from Word works well (according to Drupal people in #1580210: Figure out what WYSIWYG editor to use). The sanitization system should allow us to reliably prevent XSS attacks.
    On a sidenote: things like oEmbed can also be implemented this way — maybe we can use this for automagic Media module integration, i.e. paste a link in the body and it becomes part of the Media library?
  • Custom UI: well-defined API in place (in the jQuery UI branch), they also use this to implement the default jQuery UI-based UI .
  • Size: Aloha is getting much smaller; the numbers are from their yet-to-be-pushed jQuery UI branch.
  • Tests: another branch has moved most tests "back in the green".
  • Mobile: becomes the point of focus once the jQuery UI migration + follow-up clean-up is done.
  • Timeframe: jQuery UI branch by beginning of July, "very good version" by end of August.

For the sake of the discussion at hand: please assume that Aloha Editor is going to be adopted into Drupal 8 core by, say, October. Clearly, this would need a lot of integration work. But that's not the point. The point is: could it work?, does Aloha Editor have a future, i.e. is it the right long-term WYSIWYG choice?, etc.

What are your concerns?

Comments

This looks really good. The size thing is excellent news. Can't wait to see the final numbers!

I've started doing some playing with the blocks and parsing from a custom tag as we talked about in #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up. I'll let everyone know what I find out, but so far it seems like it's going to be very doable and provide us with a mechanism for custom setting dialogs for certain input filters, like image caption and media.

I expect timing will be important, for including in Spark and/or D8 core. It might be worth making some sensible estimates as soon as possible.

Aloha Blocks requires DOM nodes to function, so upon editing, "[site:name]" should not be rendered as "drupal.org", but as e.g. "drupal.org".

That will be difficult I think when considering a filter might change:

"I am a piece of plain text"

into

"I am a piece of plain test, with a bit more" (i.e. you can't add a tag with a data attribute around a piece of plain text, without corrupting our sense of true wysiwyg, can you?)

or this sort of methodology in terms of data attributes to accommodate tokens as in #1 might change:

[I am a token}

into

<div data="I am the initial part of the token 'I am a token'">
  <h1 data="I am part of 'I am a token', a h1 child of the div created by it">
     I am that token's h1 heading
   </h1>
   <img data="I belong after the h1 child of the markup created by the token 'I am a token', but still belonging to it, so don't save me as part of this in page editing either" />
   <p data="I am a massive paragraph that gets appended after the img in the token 'I am a token' style="fashion: fancy;">
      I am that massive paragraph's plain text all over again.
   </p>
</div>

As per:

Overall, it seems this would work pretty well.

given what was referenced in the issue in #1 #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up I think you probably know better than me, and the data attribute can handle all this?!

@#3 - actually it works pretty well with the Aloha blocks module. Check out the top demo here:

http://aloha-editor.org/builds/development/latest/src/demo/block/

It has non-editable inline items inside an editable block. It just uses the outline css property to highlight that area. The next one shows a nice example of a block-level items too. It really looks like they put a lot of thought into the blocks. It's far, far better than the placeholders that CKEditor uses.

@#4 it still relies on at least one tag to encapsulate whatever markup a token (or whatever) generates though, doesn't it?

"I am a piece of plain test, with a bit more" (i.e. you can't add a tag with a data attribute around a piece of plain text, without corrupting our sense of true wysiwyg, can you?)

Yes you would need a span or div to wrap it all (the filter's module would decide if it's block level or inline), but you can style those enough to not break the layout. See http://drupal.org/node/1605412#comment-6083498 . I've been doing some playing and got a very rough bit of code to do what we are talking about today.

but you can style those enough to not break the layout

Doesn't that break the idea of true wysiwyg where we don't have to bother about that sort of thing? If we do have to bother about it, aren't we better off using one of the properly established iframe-based editors? And still there's the case of html elements within elements, are they ruled by the data attr in the element that surrounds them or independent?

There are no valid html tags apart from comments that don't affect output, AFAIK. Nor are there any custom tags we can use that aren't invalid.

I disagree with #7 I think this really embraces what a wysiwyg should be. You can have dynamic complex content that is easy to manage and doesn't put you in div/table hell. Yet you get an accurate representation of what it will look like without needing extensive wysiwyg site theme integration. There aren't any iframe solutions that come this close to what clients/human beings envision when they think "what you see is what you get".

Many times I have had clients that really wanted the text and colors in the wysiwyg to match the theme. Well, the theme was a pattern background with a partially transparent background. Most of the time this is a doable situation with an iframe solution but it's not simple to implement properly and still doesn't achieve an optimal solution because you leave the context of the surrounding content.

I think "Aloha blocks" have potential to be very useful and intuitive provided there is a sane way to select them and change their "tags/properties". Maybe allowing you to place a block then click/double click/right click and edit its properties based on its type like:

  • float left/right,
  • inline/block,
  • image style,
  • height/width
  • D7 display mode type (small/large),
  • views display id (block_1, block_2, page_3)

There are no valid html tags apart from comments that don't affect output, AFAIK. Nor are there any custom tags we can use that aren't invalid.

There are all kinds of widely supported tags that do nothing or almost nothing. <var> and <ins> come to mind. I have never used either of these tags, and they validate.

I think "Aloha blocks" have potential to be very useful and intuitive provided there is a sane way to select them and change their "tags/properties". Maybe allowing you to place a block then click/double click/right click and edit its properties based on its type like:

float left/right,
inline/block,
image style,
height/width
D7 display mode type (small/large),
views display id (block_1, block_2, page_3)

I think you are thinking too narrowly, the options should be handled by whatever input-filter is generating the output. That way all kinds of content spesific options can be utilized. For example the youtube filter could give options for the width, quallity, autoplay, [etc] of the video.

#7 - I suggest looking at the iFrame based WYSIWYG. They already add in markup to deal with such things. Place a YouTube embed code inside of TinyMCE or CKEditor. Do you see the actual embed? No, because they are using placeholders instead. It has already been determined that there is no 100% way to ever achieve true WYSIWYG.

Any special markup for placeholders should only be put in during the editing process, via an AJAX call. Let Drupal "prepare" the content for editing and then that is what you are going to work with. And since this special markup is injected during editing, validation isn't of that much concern, though the new method I outlined in the other issue doesn't even inject custom tags. It pretty much simplifies it. If you specify that your filter is injecting a block level element, then it is wrapped in a div. For inline, a span.

The problem is that we need a way to edit the actual special tags which are parsed in filters, such as [caption]. We can't let the raw code be edited because 1) it would break for anyone not using Javascript that might edit the post and 2) A lot of tags inject code that is disallowed by filters.

Given #2 above, so I have a filter that I can use on my filtered HTML format. That filter has a custom tag, like the caption tag. That tag inserts a div, but that isn't allowed by input format. If the raw code is sent back to save, it will be stripped out of the content all together, whereas reverting it to the original custom tag, like [caption], with the appropriate attributes before save will make sure that content is properly filtered and can even be edited by people not using WYSIWYG.

There are all kinds of widely supported tags that do nothing or almost nothing. <var> and <ins> come to mind.

I stand corrected, sort of, I suppose - tags like <var>. Probably a tag like this with a data attribute could encapsulate a chunk of markup the same as a comment could. Still it seems like using a tag against design though, I mean it's a phrasing tag, like 'code'. http://www.html-5.com/tags/var-tag/index.html I found some suggestion that browsers will fallback to rendering text within this as italics, so again I say we're sort of bending an existing usable tag such that it won't be usable on a Drupal site henceforth, which seems like an awkward thing to do:

Most browsers usually render the VAR tag as italics text. If you need your text to be rendered in italics, but it is not a variable use the font-style style property.

Similar problem with <ins> <del> etc.

@#8

There aren't any iframe solutions that come this close to what clients/human beings envision when they think "what you see is what you get".

My question was rhetorical leading from what looked like the appearance of us moving towards treating a non-iframe-based wysiwyg like Aloha in the same manner we'd use an iframe-based editor, wrapping divs around inserted text so that it's no longer truly 'inline'- I'm all for not using an iframe-based solution for that very reason ;-) Given the above, though, there might be other tags we can wrap markup with, perhaps a bit more awkward than a html comment - I can see why this is used in iframe based solutions (e.g. <!--break--> - it's just the obvious one to use).

You could argue that the token representation inside a wysiwyg field is text wrapped in a div/span in the sense that what you see is "a token" and not "the exact representation of the token value". I see this as a definition issue where, for token, "what you see" is not "what you expect to see".

An at the end of the day I don't really see how we can make a token-like functionality properly work another way.

@#12 - The nice thing is using the "tokens" to wrap content (and markup) added by filters gives us a simple way to fire Aloha blocks on that content. It is then rendered the same and we can tell blocks to make that content non-editable, have it editable with a custom dialog, etc. It's far more WYSIWYG then the big players on the market have (TinyMCE, CKEditor).

I agree with you, I think lightsurge isn't convinced yet though.

Perhaps if that's the only way, fair enough, I agree it's probably still "more WYSIWYG then the big players on the market" - although the pitch here was true wysiwyg, i.e. the rendered markup is exactly the same as it would be on a straight page display, so thus my slight scepticism.

Maybe just wrap this stuff in a div rather than trying to bend an underused tag like <var> against its will, though (although I realise @frob mentioned that only to point out that tag other than comment aren't necessarily active in output).

@#15 - The rendered markup is still going to be essentially the same. Wrapping a block in a div or some inline item in a span doesn't change that rendered markup so long as there are no styling rules hitting it. The only other thing added would be any UI additions for editing, like the handle on Aloha blocks if it's draggable.

While you say "true wysiwyg" was pitched, you are never going to have that on the web, especially today. Take for example I have a custom markup [twitter id=hollyit]. When rendered that puts in the javascript to display a twitter activity block in my post.

Now I edit that post. One of two things will happen. If I don't have any kind of tokenizing, blocking of content, then when my post is saved instead of the [twitter] tag being saved, the rendered HTML from the javascript is saved (not even the javascript tag that was originally put in my the filter).

On the second part, if you have some Javascript or PHP magic going on to revert the markup injected by the javascript back into a tag, you still need a way to make that area non-editable. If not, then some unknowing editor will go in and try to change some of the body in the Twitter markup and wonder why it isn't saving.

And the Javascript thing is a real big issue here and why we need to wrap the filtered output for editing. There was talk before of marking the beginning of the tag with a comment or even data attribute, but we also got to consider elements that are added in client side instead of only server side. The client side ones are the ones that really have the potential to throw a wrench in the works.

There's also some that we have to consider even further, like advertising scripts that turn phrases in your content into links (infolink ads). Here we got a really screwy situation. The Javascript to do that isn't in the field itself, but rather in the head. That means the editor content is going to be turned into InfoLink ads and when saved, the actual links saved instead of what was intended. Honestly, I think in this situation there isn't much we are going to be able to do, depending on how the links are added.

Now I edit that post. One of two things will happen. If I don't have any kind of tokenizing, blocking of content, then when my post is saved instead of the [twitter] tag being saved, the rendered HTML from the javascript is saved (not even the javascript tag that was originally put in my the filter).

Totally agree here, there definitely needs to something identifying these elements and blocking them from editing (unless there's some plugin in Aloha or otherwise allowing direct interaction with variables in the token).

That means the editor content is going to be turned into InfoLink ads and when saved, the actual links saved instead of what was intended. Honestly, I think in this situation there isn't much we are going to be able to do, depending on how the links are added.

Again agreed http://drupal.org/node/1580210#comment-6067332 , tricky to solve on Spark's side although it could definitely facilitate a module to insert stuff like this so that Aloha (or otherwise!) can 'block' editing and not save the changes, although it could be a bit a of a pain trying to figure out, for example, how to allow changing the original text that an A tag gets wrapped around, without also saving the link.

I really don't see why there is this much confusion (unless I am the one who is confused and just don't know it).

Totally agree here, there definitely needs to something identifying these elements and blocking them from editing (unless there's some plugin in Aloha or otherwise allowing direct interaction with variables in the token).

Aloha Blocks

The plugin then allows custom parameters to be entered in the Aloha UI. Thus the content inside the div/span is not directly editable.

Sorry @frob I was just being a bit continuallly (irritatingly!) sceptical about divs/spans being used. I just meant that I agreed in principle with Jamie Holly that definitely some identifier like this should be used so we can block these areas from being editable using aloha blocks (and then plugins interact with whatever feature is in there instead, as you say).

I am just going to write out how I see this working, let me know if you all think this is a good idea or if there are problems with it.

Structure of Content Type:
Title:title
Body:text/summery
Image:image
Attachment:File
Link:url

For sake of brevity I will limit the use case to the image field and the user in this sense is the content editor.

User clicks the insert image button, image upload field comes up (in a modal or in the Aloha UI by other means) then the image tag is inserted based on the image field theme handler (it could have a custom attribute in the img tag or it could be wrapped in a div).

The same workflow could be used for attached files or hyperlinks.

If the image already exists then if the user clicks the image and options for the image are displayed (in a modal or in the Aloha UI or by other means).

This would be the same for any other type of data inserted via an input-filter.

Therefore, no data that is replaced by an input-filter (such as [twitter id=hollyit]), or the javascript that is replaced with, nor the final rendered view is editable or saved directly. If there are any editable portions (such as the twitter id) then that should have a plugin for aloha written into it that can edit those specific editable parts (this should be handled by the contributors of those input-filters).

@Frob - that is pretty much it. The idea is to get the non-editable parts of body in your example to be marked properly by Drupal and Aloha (or whatever) take the appropriate actions necessary for it, and then revert it back to the same type tag that originally generated it in the beginning.

I got a demo up using the method I described above and on #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up to parse and prepare filtered items. This method does require some core changes and contrib changes to utilize the new wrapper functions.

http://ipe.hollyit.net/node/1

You can read the basic flow and code for what I got going on here:

http://drupal.org/node/1605412#comment-6083498

It's a very basic example. I say when editing this regions, it will be best to use the sidebar to enter attributes.

The necessity for the "wrapping of tokens" and related filter problems is going to apply to whatever WYSIWYG we end up choosing. So let's please continue that discussion in #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up and focus this one on Aloha-specific concerns :) Thanks!

It's a very basic example. I say when editing this regions, it will be best to use the sidebar to enter attributes.

What do you mean by that? I don't think that any area of the site should be taken over during editing. If there is a way to expand the normal Aloha UI then I think we should do that instead.

@#24 - I'm talking about the sidebar in Aloha editor (part of the Aloha UI). It's designed for things like attributes. You access it by clicking the little black ribbon on the upper right of the page. It's just right now there's a lot of dev going on there with the jQuery UI migration, so I didn't want something that would break tomorrow.

@#25 ~ That is a good example, I just wanted to make sure that we where not taking over the Drupal sidebar region.

Can that "Sidebar" be put on the top of the window (to act more like a drawer? Also it would need to be much more noticeable (I didn't see it before you mentioned it). My main concern with using it is that it splits the UI, it would be best if everything was in the same place or if the main UI (the floating toolbar thing) had a button that opened up the drawer for more options.

We need to find out just how theme-able the Aloha UI is. That might mean finding out how far along the jQuery UI integration is. Is it time to start a sandbox, or should we be working with the current Aloha Drupal Project as a starting point?

They don't have many options for the sidebar, but since they are in the process of moving to UI, they would probably be open to adding some.

The only problem I see on it coming from the top is that you got some people out there that have a million toolbars in their browser (Firefox usually) and the height of their actual document window is so small. I don't know how these people can live like that, but they are out there and they are common! IMHO I would love a total UI that stuck to the top of the page and had the floating toolbar and sidebar incorporated into it.

Of course on things like handling of custom tags, it could be made to open the sidebar automatically when that element is clicked on, edit bug clicked, whatever we come up with. That would help out a lot.

I don't have any problems with the floating toolbar. I actually think its a good solution to a odd problem.

With regard to the problem of (some) users have too many toolbars in the top of the window -- my opinion is that this functionality isn't for the lowest common denominator and so we shouldn't worry about them too much.

It's a little long, but I recommend reading all of the Spark issue #1580210: Figure out what WYSIWYG editor to use. There's a lot of overlap between these two threads, almost enough to mark one as a duplicate (especially since a decision in one will invalidate the other).

It seams like there are a lot of parallel Drupal 8/ inline content editable discussions going on right now. Maybe a meta issue would be good for keeping everything in track.

Issue summary:View changes

Fix link to Google Doc.

Ah, I missed that. Added a reference to the original thread in the issue summary (snuck it in in Wim's voice, hope that isn't too weird).

Perfect — thanks :)

My concerns with Aloha were:

  • Size. +1mb was a total dealbreaker. The ~200kb posted in the google doc looks much better, but even smaller would be nice.
  • UX customization. If the editor is themable and it's behavior is configurable (floaty-zoomy, top of the page, etc.), all is good. Being able to configure editor behavior on the admin/ node edit form so that it follows established patterns and choose no-animation to lessen the load on mobile cpu's is a must.
  • Pluggableness. Adding plugins is great, but removing default plugins would be fantastic too. If I don't ever need table editing, dropping that js from my build would be a good thing for low bandwidth performance.
  • Mobile. The more complex an editor is, the more likely it is to choke on mobile. It sounds like there's going to be work done on mobile testing and integration soon, which is good news.

Although WYSIHTML5 is still the editor that excites me as a minimalist, Aloha is looking much better now. If I can strip out the animation, config a custom build with just the plugins I need, and it works smoothly on mobile, it seems like a great choice.

@RobW: Agreed on all counts. To answer a few of your questions: yes, Aloha does support only loading functionality you need, so it'll definite be possible to not load the table editor — hopefully it will even be possible to load it on-demand! :) Regarding mobile: this will be their next point of focus after the clean-up/refactoring/migration to jQuery UI they're currently doing. It's indeed essential for the future.

Version:» 7.x-1.0-alpha1

I was playing around with the current versions of the plugin and library and must say I'm in love with the possibilities. I'm quite interested in being able to add images inline with text and the drag and drop functionality potentially looks good, even though there are kinks that still need to be hammered out. One thing I don't see in the module is any kind of security feature which gives the option to only allow editing of your own content vs opening it up wide for all to modify everything, but that may just be due to me being new to this. Would a hook need to be written to deal with this in the aloha module, or is something actually there which I'm just not seeing in the permissions.

Anyway, really excited about the possibilities for this vs the CK/IMCE/WYSIWYG mashup I've been working with.

One update that actually just hit us today - the ability to autosave is nice, but I believe it should be configurable. My wife actually lost a full page of data because she clicked in, was editing it, and then when dealing with our son, highlighted the whole thing and pressed delete and clicked out of the field. While this was unfortunate (and she was able to rebuild it, thankfully) she was pretty pissed off that there wasn't a "Are you sure?" pop up. Any thoughts on something like this being put in?

It would be nice it it saved it in a draft revision and then you could hit the save button to publish your changes.

Issue tags:+Spark sprint 1

As mentioned at http://wimleers.com/blog/spark-update-wysiwyg-choice, there's a sprint happening at the Aloha offices in Vienna next week in order to help address some of these concerns. Thanks for all of your feedback!

Tagging for this sprint.

Assigned:Unassigned» Wim Leers

Assigning to Wim.

Status:Active» Fixed

I'm going to go ahead and mark this fixed. These concerns and others were brought up w/ the Aloha folks at a sprint in Vienna, and there's a great plan going forward to address them. Watch http://www.sparkdrupal.com/ for a summary blog post coming out this week or next.

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

Added a reference to the thread that spawned this one. Don't have time to refactor into the standard issue template, so just slipped it in as if the op had said it -- hope that doesn't offend.