We need this to work on both the front end (inline editing) and backend (full node form).

From Wim Leers in #4:
I've been working on a solid comparison of the WYSIWYG editors that meet Spark's WYSIWYG goal.

Those goal is:

What we want to achieve is that previewing content through some sort of action is no longer necessary, because you're editing the content while it has its eventual styling, in the exact context where it will be used. In other words: the exact same CSS is used as the one that will be used when regular visitors view the site! You’d be able to just click on the node body and start typing, with some box-shadow-ish indication to make it clear that you’re editing the body, plus a formatting toolbar above the node body (which might follow along as you type). This is what we call “true WYSIWYG”. We can define it as a WYSIWYG that matches all CSS selectors identically like the eventual document would.

For all information, see the Spark: WYSIWYG editors evaluation Google Doc. We'd like you all to give feedback and update the Google Doc!

We're very much looking forward to your feedback! :)

See #1260052: Candidate WYSIWYG editors for a related discussion.

Comments

Panopoly is using TinyMCE FWIW, and so is WordPress.

#0 That, and basically all the issues in that quicksketch sandbox (Bring WYSIWYG to core) are related:
http://drupal.org/project/issues/1088256?status=All&categories=All

Interesting the discussions about Accessibility. (Is it a Spark goal ? , or usability will have higher priority ? )

Since the target is Drupal core, both accessibility and usability are primary goals. :)

I've been working on a solid comparison of the WYSIWYG editors that meet Spark's WYSIWYG goal.

Those goal is:

What we want to achieve is that previewing content through some sort of action is no longer necessary, because you're editing the content while it has its eventual styling, in the exact context where it will be used. In other words: the exact same CSS is used as the one that will be used when regular visitors view the site! You’d be able to just click on the node body and start typing, with some box-shadow-ish indication to make it clear that you’re editing the body, plus a formatting toolbar above the node body (which might follow along as you type). This is what we call “true WYSIWYG”. We can define it as a WYSIWYG that matches all CSS selectors identically like the eventual document would.

For all information, see the Spark: WYSIWYG editors evaluation Google Doc. We'd like you all to give feedback and update the Google Doc!

We're very much looking forward to your feedback! :)

This request for feedback has now been announced at:

I really like WYSIHTML5; should work both inline and and on the back end, spits out semantic HTML5, is open source (MIT License, which IIRC is GPL compatible and we can use), provides all the basic styling we'd need, and (although I haven't tested it yet) apparently will strip out all of Word's nasties on paste. It also has some niceties like supporting CMD/CTRL Z for undoand CMD/CTRL+Shift+Z for Redo, super tiny, is JS Library independent, and if your browser supports Speech APIs (like Google Chrome), you can have speech input (go try it, it's super crazy cool).

Credit goes to I believe Chx for pointing this out on Twitter a few days ago, but I really love it and am going to start using it methinks.

Aloha looks like a mature project with solid development team. Some of the things I like about it: custom plugin-creation (we use CKEditor currently in our D7 installation with several custom plugins) and true inline editing capabilities (though I don't believe a complete merger of node viewing and editing modes is desirable, if only for the administrative fields that usually accompany a node).

I don't know if the size of the Aloha-editor is a real issue, it seems to me that's more of an optimization (nice to have but not paramount). In short: it looks pretty damn awesome.

WYSIHTML5 looks promising (very cool that speech editing), but currently it looks too basic for our editor's needs...

What are the ideas on integrating the body editor in the content editor? On the node form, will it just sit at the location of the set field order (pretty much like D7)? And for inline editing, what do you want to do with administrative fields that apply to the node, or is the inline node editing only meant for body-like fields?

Anyhow, developments to look forward to!

#6: wysihtml5 is under consideration. See the Google Doc for an in-depth comparison! It has serious limitations. chx probably saw it on Hacker News a few days ago. Please read the doc first before discussing it further.

#7: Indeed, we don't want to drop the ability to go to the full node form, if only for "meta" things such as "sticky", metatags, URL alias, etc. They're working on reducing the weight significantly.
We're currently focusing on inline editing only. We hope to make it possible to edit every visible field (i.e. one that has visible output) inline editable.

Having read your doc Wim it certainly appears Aloha is heading exactly in the direction Drupal needs. WYSIHTML5 sounds too basic and the dev reluctant to make it anything more than what it already is.

For me Aloha "is the one".
Is there a deadline for choosing a prospective wysiwyg?

I would personally recommend https://github.com/xing/wysihtml5

very small overheads, very semantic, pure CSS output.

Just noticed it's already in the comparison google doc.
Aloha looks great, but way too many overheads for mobile/slow machines to handle.

Could you link to the conversation where the owner of WYSIHTML5 said he doesn't think it would work well for Drupal (mention in the google doc), that would be interesting to read.

For me the benefits of having all drupal input forms using clean semantic HTML5 should be a massive priority and benefit for Drupal.
IF we need to add support for nested lists and tables, we could simply fork the project.

quicksketch had some things to say about wysiwyg editors after spending a lot of time researching them: #1286004: Research/Build suitable captioning system for inline images

Of the two, definitely Aloha (or Hallo) for me.

Besides the issue of limited functionality, I like the idea of moving away from use of iframes in wysiwyg editors. It seems like at a performance cost, we chop users' browsers into independent pieces, and then take efforts to try and hide the fact and convince the viewer it's all the same page, often with ugly results. I would rather hope contenteditable (or something based on the concept) was usable now.

I realise wysihtml5 uses iframes for security however, and security is a question mark on your googledoc for Aloha.

Aloha for me although Ctrl + Shift + arrow keys doesn't work to select text whereas wysihtml5 does.

We've used the existing Aloha module (http://drupal.org/project/aloha) on some projects, and we're very happy with it. I'll ask the maintainers to join in on the discussion.

Experimantal thinking: In my opinion, we should also link this conversation with Blocks and layout; ordering editable panel panes inside of aloha would be interesting (and not so far from how some modern newpapers do their desking today).

http://aloha-editor.org/

This would be a massive change of editing paradigm for Drupal, but something I think we should be moving forward to. The power to simply "click on something to edit it" is a goal line LOTS of CMS' have tried to reach, some have? some fail... I think being able to edit ANY editable content in such a manner, be it in a block? panel, node... would be pretty awesome.

#14 - block and layout editing sounds interesting.

As far as i'm concerned the UI for Drupal should be drag & drop in specific areas and inline editing for content updates regardless of whether it's a block, panel, article etc.

This kind of interface I believe would bring in newer users who wouldn't feel so overwhelmed with Drupal.

I agree 100%... gotta figure out how to make sure this works in the "config export" or "config in code" work though.... I'd hate to see us back to having a layout stored in the database again, and stuck there.

If mobile is a consideration, the low overhead of WYSIHTML5 is a huge win. It has some problems right now (<br><br> instead of <p>'s? Really?) but due to its simplicity seems a better fit for a wider array of use cases.

Is there a reason that Spark is moving away from the WYSIWYG API method, and choosing one default editor?

RobW: I think the basic argument is that something like WYSIWYG API means lowest common denominator thinking, and the lowest common denominator is REALLY REALLY low. Also, it means you pretty much can't do any real integration between the editor and, well, anything else because you cannot abstract the various APIs enough to leave anything useful when you're done.

As one of the Aloha module contributors I've talked with Rene Kapusta who is one of the Aloha Editor core team members and also at least semi-actively involved with Drupal. He has a lot of plans and a lot of interest in integrating Aloha with Drupal. He has been doing this experimental project with Aloha (Aloha Editor + Apache Stanbol + Drupal 7 = Semantic CMS) http://semantic-cms.info/ and I really think that he is the best person to comment on Aloha Editor development. I will contact him and ask him to join the discussion here. What also is cool is that project is partly funded by the European Commission.

I personally see that Aloha is the better candidate of these two that have been mentioned here (Aloha & wysihtml5) as I'd like to see editing possibilities also on the front end side and not just on the backend side. It's faster to do minor fixes on front end and on front end you actually can get the real WYSIWYG editor feeling because you have all the right styling and context available. Please do correct me if I'm wrong with the wysihtml5 in this case because I haven't had time to really check that one through.

EDIT: I somehow missed that my above point was already mentioned in the basic stuff concerning Spark. But still I can't really find information on how wysihtml5 would solve the front end editing requirement.

Crell: thanks for the explination.

As an aside, there's a (short) discussion of inline editing in #1514272: Inline Editing and the WYSIWYG module in the WYSIWYG issue queue. Sejute suggested building a separate Inline Editing API that would do something similar to WYSIWYG API, provide a standardized way to attach editors to fields or contenteditable areas on the front end, and posted a github proof of concept. [edit] Not suggesting that's the way to do things here, just including for reference.

Back to editors, I personally could not use Aloha with any client work soley because of the interface decisions they've made. The slidey-floaty follow you around paradigm they're going with is horrible UX in my opinion. WYSIHTML5 is definitely younger, but seems lighter, more configurable, themeable, and extensable -- add some js and a link and you have your own custom button and functionality. It has so few moving parts, the adaptation to mobile should be painless. It's simplicity is it's strength.

For me, I have no really strong preference provided that I'm still able to build something and leave it out entirely. If you make it so that I can't type into this comment form without dealing with 400KB of Javascript that tries to pretend it's MS Word, then we'll have failed utterly.

Aloha!

I also think that Aloha Editor would be a good decision.
There are also integrations for WordPress, Typo3 and others...
* http://scribu.net/wordpress/front-end-editor/fee-2-2.html
* http://blog.kay-strobach.de/index.php/2011/07/04/aloha-editor-im-typo3-b...

In the sense of "decoupled content management" ( http://bergie.iki.fi/blog/decoupling_content_management/ ) it would be good if also Drupal would support / use AE -- users will like to use this new approach with less clicks and real WYSIWYG everywhere ;-)

AE has a lot of advanced features like the Repository API* -- all nodes and asserts are available as type ahead result when you insert links; minifying the code is also important and there are other issues on the roadmap...

If you need advanced features you should use Aloha Editor (for cms content editors)
If you need less features but a small fast editor loaded (js core) then wysihtml5 is a good option (eg. for comments with less formatting options)

*) screencast: http://semantic-cms.info/media/semantic-cms-drupal-inline-editing-via-rd...

All the best,
Rene

Here's some information about Aloha Editor + Apache Stanbol for D7:
http://munich2012.drupal.org/program/sessions/aloha-editor-apache-stanbo...

@robw #21

As regards to the follow you around stuff... I see that already, I have B, I and ABC above me right now. If I had 3 textareas to fill in to complete a piece of content based on fields, or several pieces of content that make up a page, I suppose I'd have 3 lots of that pestering me, which is repetition I'd prefer not to have.

I mentioned in another thread that I was impressed with Whizzywing http://cloud.github.com/downloads/unverse/Whizzywing/whizzywing-demo-cus... which I suppose aims to do everything I'd personally like a WYSIWYG to do, at 17k, apart from the follow you around stuff you mention that I feel Aloha does so well. Which I suppose is where the weight comes in.

Wysihtml5 is very similar (besides my hated iframes)... and with a gui bootstrapped around it it looks great, as far as a straight page goes. But where's the demo of multiple editable parts to a page? I'm not sure it even has its eyes on this sort of inline/backline multi-region CMS editing job with as advanced as you want functionality, as @Wim Leer in #4 has already documented.

I totally agree though with @Crell that size matters :-D I tried http://semantic-cms.info/ from #20 with Aloha library and it was very slow to initially start, by the size of the js... Considering that what I like about it results in what a 17k library can do, is the UX worth multiplying the size by tenfold, I'm not sure. But for me I do like the follow you around stuff ;-)

@lightsurge: Whizzywing looks quote good if a little buggy, and I found it quite slow on iOS on my iPhone 4, there was a notable delay in the characters displaying when I type. In comparison, I tried the semantic-cms site with my iPhone and the editor was much snappier, as responsive as entering text in a normal app, but the toolbar didn't work very well.

Meh. Any other options?

@DamienMcKenna yeah I had the same thing with Whizziywing in IE8 but with Chrome it worked fast as hell, but yeah, therefore definitely buggy. I wasn't really submitting Whizzywing as a possibility for Spark, more that I was pleased to find something that underlined the sort of idea, and a decent array of features while at the same time incredibly minimalistic. Helped me understand the difference between the 'job' and the UX, one of which seems apparently not easily compacted.

Lamp the user interface on top of wysihtml5 and it's not exactly the skinny beast it is unclobbered.

I think other options are thin on the ground really, Wim Leer is probably right to narrow it down to these two. Although I do think, saying Aloha, surely it could either be Aloha or Hallo (which could be a lot lighter, treated right) which are essentially the same beast, or indeed some WYSWYG based on the stripped 'standalone' Aloha with a custom UI. I think Wim did mention this but perhaps if someone could emphasise how Aloha might be used (since wysihtml5 is pretty obvious, bog-standarded buttons or twitterish bootstrap, and is pretty clearly demonstrated), otherwise this issue could get focussed on Aloha's size/user interface in comparison.

@lightsurge: I assume that a non-floating editor's toolbar would only appear on an editable area when it has focus.

Ok, that's enough for me. I cede the floor to others more invested.

Please don't use the implementation of Aloha Editor at the Semantic-CMS.info demo page for comparison!

  • It's AE with Stanbol and other experimental stuff.
  • It's the old 0.9.x version.

The latest release of Aloha Editor (with applied hotfixes) can be found here: http://aloha-editor.org/builds/hotfix/latest

Boilerplate demo: http://aloha-editor.org/builds/hotfix/latest/src/demo/boilerplate/
Aloha Editor Guides: http://aloha-editor.org/builds/hotfix/latest/doc/guides/output/ (not everything up to date)

Regarding the UI / UX:
There is also a work in progress branch of AE using jQuery UI instead of extJS for the UI components -- https://github.com/alohaeditor/Aloha-Editor/tree/dev-jqueryui (this will make the whole thing also smaller)
This means Aloha Editor's toolbar / floating menu / sidebar and buttons are fully styleable...

If you need to edit content in the backend you can also use AE like you've used traditional iframe based editors in the past.

BTW: jQuery 1.6.x is now built-in in the aloha.js -- replacing that with the one used by Drupal will also reduce size. Also cleaning up will reduce the size... I think there are at least two plugins which have the same 3rd party libs...

You're welcome to contribute to reduce the size and improve what's already here and add what's needed ;-)
Fork Aloha Editor: https://github.com/alohaeditor/Aloha-Editor/
Contribute: http://aloha-editor.org/contribution.php
Communicate: https://getsatisfaction.com/aloha_editor

I assume that a non-floating editor's toolbar would only appear on an editable area when it has focus.

I'm not exactly sure of your point here, unless you mean you'd prefer the UX to not involve a floating toolbar and to appear in the traditional sort of way as on drupal.org, but only on focus. I'm okay with it floating... I suppose it could get a little irritating as in http://semantic-cms.info/node/9/edit example if I have to move the Aloha editor to be able to click in the title field. And I suppose, to be honest, that's probably the only time I'll actually want to move the editor ;-) I think the UX decision here might be to underline the impression of true wysiwyg, in that because the editor is floating, it's not part of the page, it's detached, and so therefore not affecting the output at all as it would if it appeared (attached) on field focus and took up page space. That's why I'm okay with it as a UX win (even tho I that only really applies for inline editing).

I'm not sure if it would be better if Aloha's editing control's appeared in Spark's admin toolbar (since I suppose that's Drupal's method of attaining the same UX win) instead of floating over the content, is that possible with Aloha? The flip side of that coin is that with text editing controls, because they're inline tools, I probably want them as close to my cursor as possible, so bunging them in the admin toolbar would probably be detrimental.

On that topic it's worth checking out http://hallojs.org/ to see Hallo editor, Aloha's quieter brother, which seems to clock in at only ~70kb and is already a jquery ui plugin. The toolbar will only appear if you select text in this example (which I suppose is good UX for inline editing).

To clarify my previous statement, size matters but that's not what I was talking about. I'm saying that whatever WYSIWYG we end up using, and I assume we'll end up with a default one baked into D8 core, it is useful for only a small handful of use cases. Those use cases are very common ones ("edit this page node I'm looking at" being a biggie), but there are dozens of use cases where I want a form on its own page with a basic textarea, as we have now by default. This comment form I'm typing into right now is a good example.

As long as I can still build a "click edit, get new page" or "click reply, get new page" etc. type site with no WYSIWYG, and it doesn't require the sorts of contortions and second-class-citizen setup that WYSIWYG does now, I'm satisfied and have no strong preference as to which editor we use. I just want it optional.

Yes, to be clear, even with the most awesomest inline WYSIWYG editor ever, you still need to get to the full node form. Both for creating nodes the first time, and also for editing non-visual properties such as whether the node's published or not or its friendly URL.

Understood, although, this comment form I'm using now still has an editor... and surely it can't be that much of a stretch to have an editor like Aloha present user input in rendered html, markup, or nothing at all (based on user preference). Like #1586404: Revamped WYSIWYG designs.

Definitely agree it should be easy for admins to get rid of and/or interchange for a different editor, though.

Hope its not too late to mention Redactor, one I came across this week:

http://redactorjs.com/

I've used CKEditor for years, and the junk markup it injects always bothered me (to which you need to add HTMLPurifier etc to keep markup clean- that you aren't even entering yourself).

At a bare minimum, the basic formatting (bold, italic, link, etc) needs support as well as being able to insert a table, image, and file. The last 3 are also critical to basic content management.

Something I really like with the big dogs (CKEditor and TinyMCE) is their paste clean-up. So many times I have seen an editor go to crap from arbitrary code being pasted in from another site. It would be nice to have that in whatever editor is chosen.

If TinyMCE is chosen then we need to keep in mind that it is a little cumbersome loading it crossdomain. You have to set document.domain in order for it to work properly. Not a big deal, but something to keep in mind.

@Jamie Holly all iframe-based editors are out of scope according to #4

Although, wysihtml5 is iframe-based, difference being that it uses contenteditable rather than rendering textareas. I'm guessing that for this reason, despite using iframes, in its particular case input will still get site consistent styling from theme stylesheets, and that's why it's included here?

I'm asking the question really because I don't know, I would have assumed it would still have some styling inconsistencies and be subject to some resource re-loading by virtue of its iframes, but since I'm no theming expert I'm pretty sure I must be wrong if it was selected for consideration here.

@ #35 wysihtml5 can be hacked to remove the iframe, that's why it's considered here.

Thank you for all your feedback! I'll try to reply to all unique questions/feedback, not to every single thing said.

Just to clarify once more: we wish something like Aloha Editor was super mature, super fast etc. But that's just not the case. We do have clear requirements/goals though: we want it to be "true WYSIWYG". That excludes all iframe-based editors (note that they also have inherent performance problems). That does not imply we'll accept any level of code quality or any size of JS.

To those commenting on Hallo: yes, it's much lighter, and it appears to be able to do almost the same. But it can't. For the basics, it's great. But a lot of functionality is missing (intentionally), such as table editing. That requires a lot of code, unfortunately. We'd be happy to be proven wrong here though :)

#9: No, there is no deadline yet. I think we'll make a decision when we feel like we've gathered solid feedback and we feel like we can make a good decision.

#10: I can't link to that as it was said in an e-mail to me. However, you can take my word for it that I did not strip out any other meaningful information. In the Google Doc, I've included all relevant information — I want us to make the best decision possible, and that's impossible if you all don't have the complete package of information!

#11: Thanks for that link! Especially #1286004-1: Research/Build suitable captioning system for inline images and #1286004-2: Research/Build suitable captioning system for inline images are very useful.

#13: Getting shortcuts to work should be easy enough :) That's just a minor problem.

#14: Blocks & layouts are out of scope for this, at least for now.

#18,#19: WYSIWYG API indeed prevents very tight integration. That, and we don't want to force the user to manually install a WYSIWYG (WYSIWYG API + downloading a WYSIWYG manually are currently required). At least for Spark. Our current thinking is that it'd be good for D8 to ship with a WYSIWYG that requires zero configuration, but that users can then of course disable/override it. But that's all to be decided in the (still) distant future, of course :)

#20: wysihtml5 could also be used on the front-end if we make some changes to wysihtml5 (see the Google Doc), but it's got severe functionality limitations (forever, as in, they will not be implemented).

#21:
- RE: seutje's proof of concept: #1514272-6: Inline Editing and the WYSIWYG module.
- The problem with wysihtml5 is that it does not support advanced features and never will, such as support for tables.
- I agree that Aloha Editor's floating toolbar is problematic on mobile devices. Or rather, the floating itself is not per se a problem, but the way it follows you around is currently making it harder than necessary to use.

#22/#30:
- As webchick already said, the ability to go to the full node edit form will definitely not go away. Basically, everything remains as it is now, with the addition of being able to edit right on the resulting pages with "true WYSIWYG". Yes, that brings inconsistent editing behavior with it, because "you can on the back-end and on the front-end", but it's a big step in the right direction to make it easier for end users.
- 400 KB is indeed too much. It may be somewhat acceptable on desktop, but it's prohibitive on mobile. Aloha Editor maintainers are saying it's going to be reduced significantly. We'll need to talk to them closer to figure out what its size is going to be.

#23: I completely understand your point about using Aloha Editor for "CMS content" and wysihtml5 for "comment content". You could extend that further: use Aloha Editor on the front-end, wysihtml5 on the back-end. But won't that cause issues in terms of mixed mark-up?

#24: Thanks, I didn't know about Whizzywing! While it seems to work relatively well, though a bit buggy. The website http://whizzywing.com/ and especially the GitHub repo (https://github.com/unverse/Whizzywing) seem to indicate that it's a fairly immature project. Also, did you give a look at the JS code? It appears the author is writing near-minified code by hand: https://github.com/unverse/Whizzywing/blob/master/whizzywing.js — that's an impressive feat, but one that makes this piece of code super hard to support and extend.

#26: The probability is very high that we'll go with a custom UI, regardless of the WYSIWYG editor we pick :) If we'd end up choosing Aloha, then its toolbar would most likely not float as it does now.

#28: It would be tremendously helpful if there were a chart somewhere showing the distribution of code weight in Aloha: A) Aloha core, B) Aloha plug-ins, C) 3rd party libs. Preferably, this chart would be generated automatically for each build, so that we could easily see the current state. I think this would be very helpful for many developers trying to choose a WYSIWYG.

#29: That's also my interpretation: "the toolbar floats around as you move around, because that makes it clear its something that sits on top of the actual content". Hence "true WYSIWYG" is stressed.

#33: Very interesting! This one unfortunately also uses an iframe though. See the Google Doc why we don't want that.

#34: Yes, we definitely want that to be rocksolid as well. However, it doesn't need to be from the get-go, as long as we can improve it through the WYSIWYG editor's plug-in system. We know that Aloha can do this.

#35: No, wysihtml5 is included because it seems it's possible to not use iframes. See footnote 1 in the Google Doc.

Thanks for the neat summary and answers Wim.

Just to state the obvious, it seems that if we want to include advanced HTML editing features in a WYSIWYG editor (like tables or nested lists) it will require more code and ui options, and greatly increase the size of the javascript.

How essential do we think these features are?
Personally I never write a HTML table any more, Views does a nicer job, and has the dynamic content I usually need.
Nested Lists are not used that frequently, but I think these are more important than tables support.

Can we assume that users wishing to use these rare case advanced features could simply switch to HTML source mode? Or can we simply build Drupal contrib module plug-ins for them?

As RobW wisely said above, simplicity is strength, do we absolutely need to overcomplicate this with advanced HTML functions that most users will never use?

I also came across Nicedit, another iframe-free editor, but didn't try it when I saw the last release was in 2009. This is a good demo http://nicedit.com/demos.php?demo=5

The demo works so well I think I'll give it a try (appears integrated with WYSIWYG API). Maybe it's just perfect and doesn't need a new release :)

For all sites I've ever worked on save 1, clean-up of Word cruft on paste was a requirement. Most organizations which put content on their websites write that content first in Microsoft Word, and they will be pasting the content from Word into an editor field. Yes, it would make more sense in many cases to do that review on the web, but a) Drupal prior to Workbench on D7 didn't really support simple ways to do that, and b) this is just how they do it and telling them they need to do things differently in their business to accommodate THEIR WEBSITE is going to seem rude.

Aloha supposedly supports this cleanup capability (though since they don't load it in their demos, I haven't tested it). WhizzyWig and NicEdit had poor support for it last time I tested them, but that was several years ago.

Aside on the WYSIWYG API -- I've complained about WYSIWYG project in the past, but those were mostly related to the aggressive promotion of it by its exponents as the be-all and end-all for WYSIWYG embedding, BUT:

  1. The core use-case for the WYSIWYG project (different editors for different fields) remains valid, and probably does still justify WYSIWYG API in core, so I'm hoping the upshot of this decision isn't to kill that idea;
  2. I'm not clear on why WYSIWYG API encourages a least common denominator approach.

With Wysiwyg, and nicEdit from a git, with this patch reverted efa6a1e886 this fix applied http://drupal.org/node/347488#comment-5139634 and insert functionality added http://drupal.org/node/594322#comment-4088998 I have a workable little editor at less than 55k. Its toolbar can be detached from the content, and used for multiple editor instances, so I imagine it could be made to behave in a similar way to the Aloha toolbar.

NicEdit doesn't do tables full stop, no 'paste from word' type functionality either. It can do a nested list of sorts but not valid markup, same with Whizzywing. Doesn't seem to do much if anything to protect the user from markup pasted directly in, I'm not totally sure on that though. The wysiwyg itself generates the bad standards in-compliant markup that I suppose is the reason contenteditable is only just beginning to emerge after being around for so long - from the nicEdit website it looks like some effort was put into turning this into valid xhtml, but didn't get past developmental code and I can't find any clones on git that have. Whizzywing on the other hand has a function to clean this up, which might be usable in nicEdit as well:

"clean" uses a mix of DOM manipulation and regular expressions to get
clean and valid HTML from the tangled mess the browser inserted with
execCommand. Refined over many years now. Should be valid as xhtml and
HTML5

http://unverse.net/Whizzywig-2011

Apart from the fixes mentioned nicEdit actually seems quite stable.

If Aloha isn't going to be chosen (or if developing a custom UI becomes a mammoth mission), isn't it possible Drupal.org could just take inspiration from these simpler contenteditable editors, Whizzywing, nicEdit, Hallo and wysihtml5, and create a bespoke one? Although, that's alright for me to say because it's beyond my skills! :-/ Normally I would think that silly when it's better to use something that's already out there, but when you only really have 1 project to choose from...

@escoles Totally agree with you on that, cleanup of pasting from Word is a massive issue for us too.

I did a test with

<B>This text is bold</B>
<I>This is italicized text</I>
<CENTER>This text is centered</CENTER>
<B><I><CENTER>This text is bold, centered and italicized</B></I></CENTER>

of Aloha, nicEdit, wysihtml5, Hallo and Whizzywing, only Whizzywing attempted to cleanup the pasted markup and make it valid.

I know a client side filter was mentioned in #4

At DrupalCon London, quicksketch discussed the need for a client-side filter system to run alongside the server-side one that Drupal core already has, and I agree with that. So, potentially all we need from Aloha is an event that we can react to in order to filter text before it is pasted.

I think it's crucial for Spark if the intention is to have 'true' wysiwyg, otherwise much of the crud will be filtered out by the server side filter between being submitted and reloaded, making it look entirely different to what it will have looked like in the editor.

@37 It was a bit wrong expressed. I'll recommend Aloha Editor for back and front end. Not two different ones.

When content is made from editors (sitting in a company / governmental agency / ... ) writing complex stuff (which includes "heavy" MS Word / Open or LibreOffice copy & paste; [big] tables; nested lists, cites with references, ... ) -- here the (download) size is important but also not that important (when working almost daily with it, you'll have it in cache).

On the other hand there are the "website users" which load the wysiwyg libs when they navigate to the site where they can leave eg. comments... here I suppose basic stuff will be fine -- if you only need basic stuff also AE can be small (after a cleanup and without extjs).

Regarding mobile: AE have had almost no focus on mobile editing experience so far. It's definitely important but in this area there you'll also have to care about other stuff compared to editing experience and capabilities for traditional web / desktop apps.

Regarding the (floating) menu in AE:
* it can float where your cursor is
* it can stay on top of your editable area
* it can be attached to the position of any element (and stay there or stay on top of the window when you scroll)

It's not perfect, there are a lot of developments and it improves with every feedback.

The whole UI / menu is in the process of going to move from ExtJS to jQuery UI (with some improvements how it can be configured regarding position and elements fo the menu) -- and if you don't like what's there, just use the API and run something like execCommand('bold') on the selection...

@38

Can we assume that users wishing to use these rare case advanced features could simply switch to HTML source mode?

No, I don't think so.
If you work with governments, banks, insurance companies and others the like this is no option -- some of them BTW require IE7 support ;-)

@40

this is just how they do it and telling them they need to do things differently in their business to accommodate THEIR WEBSITE is going to seem rude

agreed!
As already mentioned: AE has good copy and paste support for MS Word documents (this is how some of the customers of Gentics, the company behind AE work)

@42 - I agree totally, this functionality must be present. A majority of content authors out there don't realize the nasty little things pasting can place into a rich area.

One solution is a combination of client side and server side. Basically when content is pasted in that content is sent off to Drupal along with the current input filter via ajax and ran against the filtering inside of there. The filtered content is returned and inserted in place of the recently pasted text. That would be the closest way to get what Drupal will actually output.

Considerations on this:

  • Input filters will need a "onpaste" (or better) flag. We wouldn't want all filters to parse pasted text (ie: PHP, Media, etc.)
  • Any placeholders in the editor will need escaped out so they don't get caught in the filter. For example: [media {parmas}] becomes {more markup}. We would want a way to mark this to not be processed via Drupal's HTML filter.
  • This could become rather server intensive depending on the amount of content a site gets.

I have been working on something similar for CKEditor and it seems to be working well.

@41, @42

Regarding cleanup "dirty" html: <B><I><CENTER>This text is bold, centered and italicized</B></I></CENTER>
--> that's not considered right now (although we thought about using a server side component we for now just use plain javascript)

You can listen to and hook into the "aloha-smart-content-changed" event for the paste action and send the content to a server side clean up utility like tidy or use the Drupal html filters...
See: https://github.com/alohaeditor/Aloha-Editor/blob/hotfix/src/lib/aloha/ed...

Regarding the Drupal HTML filter it would be nice to use those configs also for Aloha Editor's sanitize content handler (we would need to render them as JS config like that: https://github.com/alohaeditor/Aloha-Editor/blob/hotfix/src/plugins/comm...)

Whizzywing doesn't actually do a bad job of trying to fix pasted markup in javascript rather than just removing prohibited tags, it changes <B><I><CENTER>This text is bold, centered and italicized</B></I></CENTER> into <center><em><strong>This text is bold, centered and italicized</strong></em></center>

...but I must agree that pasted 'input' in a contenteditable would be best to go through the same filtration process as it would before ordinary display, otherwise there'll always be discrepancies, so I guess Aloha can't really help there really, because every Drupal site might be different.

A couple of pedantic heads up: <b> and <i> are valid HTML5 (although maybe not what most users semantically intend). <center> isn't, of course.

IE7 isn't an issue, since Drupal 8 will not support it by default.

@rene_kapusta - the "aloha-smart-content-changed" seems buggy to say the least. Actually in the latest version of FF and Chrome I couldn't even get it to trigger. Just the blur and keypress events seem to fire. Keypress would work, except in the case of context menu pastes. The best route would be the DOM's paste event.

Updated the issue summary with a link to the doc.

@ #47 I know, but in a sense I think Whizzywing does quite a lot of hard work in so few lines of code, without just a whitelisting effort that eliminates tags like which is surely an easier job in javascript.

Like I say tho, any javascript filtration is meaningless here, in the context of Spark and inline 'true wysiwyg' editing, Spark has to employ the same methods as the drupal 'input formats' do, which sanitise/purify markup on output. So I suppose all such efforts at sanitising/purifying markup in javascript aren't to be rated here.

@ #46: Aloha does supposedly support cleanup of text pasted Word: https://getsatisfaction.com/aloha_editor/topics/paste_text_from_word

However, they don't enable that feature on their demos.

@escoles actually the demo I used seemed to have this enabled (http://aloha-editor.org/demos/3col/ - check the script resources), using https://github.com/alohaeditor/Aloha-Editor/blob/hotfix/src/plugins/comm...

Since there's no 'paste html in here box' (which aren't great really are they, because nobody bothers to use them unless you happen to have a 'button pressing policing division'), it's difficult to tell how well it works. However, Chrome adds webkit center styles when copying pasting centered text in my example, and it did remove this in my testing so it looks to be working, it didn't change I to EM or B to STRONG but as @RobW says, these are technically okay HTML5 anyway. Can't say without [seeing reports of] further testing to say whether or not it will efficiently kill MS Word nastiness, but as I said in #50, it's probably meaningless as far as Spark goes apart from taking some work away from what will eventually have to be done by the server.

I did some further playing on http://aloha-editor.org/demos/3col/ with copy pasted from MS Word, and it did indeed work exceptionally well, so a big thumbs up from me - it'd definitely take some work off any server side filtering if it could be used in combination.

Priority:Normal» Critical

Upgrading this to critical to reflect it as a current development priority. Thanks so much for all the feedback/input so far, folks!

Related module for filtering on paste:

http://drupal.org/project/pasteformat

Can someone who's configured Aloha say whether it has a source mode? Their demos don't.

EDIT:

This page lists a 'sourceview' plugin, but the link is broken as I write this. Lots of broken links on their site.

This forum post is a little clearer: they have source viewing, but not source editing yet -- it's in the works, but it sounds like there are technical issues holding it back. So, source editing in an edit-in-place scenario: probably not. Would need to do that in the node edit form, still, at least until the source edit plugin is ready for prime time.

+1 for Aloha, looks very neat and has good support for RTL languages.

Wim Leers has (quite reasonably) dismissed Hallo in #37, but for completeness I thought Create JS (using Hallo) should have a mention (which I've just discovered because there's a session on it at DrupalCon Munich): http://createjs.org/ (http://drupal.org/project/create).

CreateJS is, I think, not so much a WYWISYG editor as it is a REST client that happens to implement an editor. I'm sure Henri will correct me if I'm wrong, but I don't think it is the same class of tool as being discussed here. (That said, I do want to be able to support it in Drupal 8 if we can. That's why we have Henri speaking in Munich.)

Yeah Aloha is looking better and better. I think one feature that should be put in is a compressor that aggregates the css and js files into single files. Not sure if that would be possible, but a pretty the simple configuration alone, which includes common/format,common/highlighteditables,common/link, loads:

  • css - 4 files
  • js - 7 files
  • images - 16 files

The list starts growing with tables, lists, etc and I can see it really growing with additional plugins.

This might be a good thing to discuss with the Aloha dev team if this is the editor we decide to use.

Something additional I just noticed. The aloha.js file is 2.2mb in size. That is huge! Then you add in the needed dependencies like UI and plugins you get 3mb. For example, the block plugin alone is almost 36kb.

A lot could be saved by going minify, but we would still be looking at over 1mb in size just for the editor.

Compare that to the CKEditor with all the bells and whistles loaded, which comes in at 258kb and TinyMCE (full featured with GZip) at 183.4kb.

Sadly I think this is a pretty big ding against Aloha and should be heavily weighed. Does Drupal want to come with it's core WYSIWYG being so heavy, especially if it is used on things like comments?

Please read the previous comments and the google doc, aloha minified+gzip is around 350kb and will get smaller once some amount of cleanup work is done (removing extjs and jquery from the build file and getting duplicated code out). It is indeed a concern and is being taken into account.

I missed the part about those libraries being removed. Still 350kb minified + gzip is rather large. If you add GZip into Tinymce it comes in at 101kb and CKEditor at 116kb. All the other editors mentioned have been even much smaller.

I think I'm more shocked by the size of Aloha than anything. Need to look more into it to see where so much bloat is coming from (minus the included libraries). I noticed the dev branch is down to 1.6mb and that's still with JQuery and ExtJS in there, so they are removing a lot of stuff.

Thanks for the continued excellent feedback! Especially all the feedback in the "paste from Word" area — which is indeed very important for many content creators! I've added this to the Google Doc. The comment in #37 seems to indicate that the "paste from Word" support in Aloha Editor is excellent. Could others please confirm this?

#38: I agree that we need to be able to only load the JS people will actually use. That's why it's very nice that Aloha Editor uses 1) a plug-in system, 2) RequireJS. The combination of the two means that we can only load the JS that is actually going to be used. It even allows us to lazy-load JS :)

On top of that, Aloha Editor's plugin-in support would make it perfectly feasible to define on a per-input format basis whether e.g. the table functionality is available or not.

While I personally also don't need a table editor, many people still actually need this. It's an essential part of the web, and for the target audience — content creators — it's an essential tool.

#39: NicEdit looks interesting. A quick test reveals some issues (as mentioned in #43), which are surmountable. But … it's been inactive since 2009. It seems dead to me.

#40: Note that we're not trying to get WYSIWYG API in core as part of Spark. I'm not saying we won't, but it's definitely not a priority. We're trying to get "a default" WYSIWYG in core.

#41: It's not feasible to "roll our own WYSIWYG". First: NIH-syndrome is bad enough as it is. Second: we don't have enough JS manpower. Etc.

#43: Thanks — very useful info!

#44: Yes, Media module support 1) will be a top priority, 2) would be a separate Aloha Editor plug-in. That'd also be a major test of their plug-in system.

#49: Thanks :) Not used to that functionality yet.

#53, #57: thanks, now linking to this issue follow-up of yours in the Google Doc

#58: Yes, CreateJS is a very interesting project. However: it's 1) immature, 2) very much out-of-scope. It does many things that are not part of Spark's scope. We'd love to work on that, but "just" getting very solid WYSIWYG integration is going to be a more than sufficient pile of work as it is :) Maybe/hopefully in the future! :)

#59: CreateJS is much more indeed: https://github.com/bergie/create. It includes VIE for RDFa. A lot of JS logic/magic. We don't want/need that in Drupal. Not yet at least.

#60: See the answer to #38; first paragraph. :)

#61/#62/#63: Aloha is indeed very large today. Too large. Maybe even prohibitively large. Imagine loading that on a mobile device over 3G, or worse, EDGE… Nightmare. This is partially mitigated by what I answered to #60.

We will need conclusive information/guarantees about the upper size limit after their jQuery UI migration is complete.

For me personally, this is the biggest concern at the moment.

NicEdit looks interesting. A quick test reveals some issues (as mentioned in #43), which are surmountable. But … it's been inactive since 2009. It seems dead to me.

Agreed, and doesn't do anything for taming browser markup (tho maybe that wouldn't matter if we had a client side filter).

Whizzywing on the other hand handles browser-inserted markup well, and I'm not sure the git repo for Whizzywing is a good indication of the participation/interest in it, the Drupal project page is better in terms of showing that people must actually be using it http://drupal.org/project/whizzywig (Whizzywing is Whizzywig 2011). It seems to match most of the core features of Aloha, but nowhere near the UX friendliness. It was a bit irritating having Aloha hovering around me like a fly, but it has so much UX in the positive - it looks the business - and I sort of hope that if Spark goes with Aloha but with a custom UI, it doesn't end up losing all these gains in the effort to cut size (as everyone keeps saying the UI is the most difficult thing for a wysiwyg, so sacrificing this to cut size seems counter-productive).

So Aloha seems best on all grounds apart from its sheer obesity. Given we're judging it on how it works now, and what makes it work like that is currently a codebase in excess of 2MB... I know, that will reduce substantially... but if I think about it I'd probably need Aloha to get down to something like a 10th or less preferably of what it currently is before daring to use it on anything but very particular projects (which don't have a ton of other javascript going on already, don't need to be usable on mobile etc., or specifically demand a juicy editor like Aloha). At a tenth we'd still have one of the bigger-in-size editors, but worth it because it offsets its size caveats in other ways.

Expecting a project like this to cut its size down by a tenth even given all the previous mitigating factors seems like a lot to ask?! Surely it's also likely to grow ;-)

You can always not load every possible plugin, that could significantly help :p

I'd probably need Aloha to get down to something like a 10th or less preferably of what it currently is before daring to use it on anything but very particular projects...Expecting a project like this to cut its size down by a tenth even given all the previous mitigating factors seems like a lot to ask?! Surely it's also likely to grow.

For me, the total size of the full codebase is not a big issue. Instead, what's a big issue is the kb necessary to do a basic edit operation (e.g., get a toolbar with bold, italic, list, link, and a few other basic buttons). Beyond this, it's up to the site administrator to decide which extra capabilities (e.g., table, paste from word, etc.) to enable by weighing the benefits against the bandwidth needed. I would hope that AE is able to get to a small enough size for a basic edit scenario, and for this to not grow with time, but shrink as more jQuery can be leveraged, and as browsers eventually become better standardized on how they internally deal with currently unstandardized contentEditable details.

as browsers eventually become better standardized on how they internally deal with currently unstandardized contentEditable details.

Well it's been a mess for 7-8 years now, I'm kind of pessimistic about that.

You can always not load every possible plugin, that could significantly help :p

*chuckles* True, but there are many instances, magazine style use cases for example, where you want all reasonable copywriting based formatting techniques available, even if certain bits are only used infrequently.

@nod_:

That would be true except the fact that this is the size of the aloha base. Plugins are lazy loaded and not included in that, which means it's not even enough to get Aloha to work. The bare minimum as far as plugins goes is common/format and common/highlighteditables. Format is 10.5k and highlight 1.7k (both small enough)

(NOTE: My sizes above in #61 was Aloha+bare minimum plugins. For MCE and CK it was base + all plugins)

Want to add links? Now you need common/links, which is 26k. Lists? That's another 27k

I've just spent the last couple hours tearing into the core of Aloha. It appears a lot of the size comes from range selection. For example, they are using Rangy to simplify range selection. That library alone is 125k. Then they have their own selection API that is another 86k. Then there are also quiet a few smaller files that deal with selection.

I'm not really sure how the development process for Aloha has evolved over the years, but it appears to me that it's the same as some site builds in Drupal. You want a single, custom layout page. Instead of doing a quick module with a few lines of code and CSS you install panels, ctools and views. Libraries are nice, but when you add a bunch for only certain functionality from each, you end up with a ton of bloat. In the Javascript world this is a real problem.

Now compare those to the size of the same functionality in TinyMCE. You've got Range, which is 18k, RangeUtils, which is 8k and Selection, which is 37k.

(Disclaimer: The numbers are skewed a bit due to Aloha doing a much better job at code documentation, but there is still a significant size difference without code docs).

The parser/sanitizers in TinyMCE (which does one of the best jobs out there IMHO!) clocks in at 95k.

Actually speaking of parsers, jQuery is a parser in itself. Sanitizing with jQuery isn't that complex either. There's even a project for it, jquery-clean, which is a plugin that comes in at 10k and offers close to the same power that TinyMCE's sanitizer does.

I could honestly see Aloha getting much, much smaller in size, but that is going to take a lot of work. Hopefully they can get it done in time for Drupal to use it because I do think it's a great editor, although I do have to echo the views of Lightsurge on the floating toolbar. It's fine if you're using it for things like comments, but it can become a pain when writing larger documents. More than a few times I had to drag it out of my way.

From everything I've seen, and webchick's demo on YouTube, to me Aloha is the clear winner, given that it supports plugins for the Drupal specific stuff.

Yeah, for those who missed it, we've uploaded a video that walks through a HTML/JS prototype of our current thinking at http://buytaert.net/spark-update-in-line-editing-in-drupal

@Jamie Holly all iframe-based editors are out of scope according to #4

And #4's actual comment:

What we want to achieve is that previewing content through some sort of action is no longer necessary, because you're editing the content while it has its eventual styling, in the exact context where it will be used. In other words: the exact same CSS is used as the one that will be used when regular visitors view the site!

I don't think iframe-based editors (read, pretty much every editor except Aloha) are entirely out of the running. It's easy enough to grab the <style> tags from the parent page (or use the list in Drupal.settings.ajaxPageState.css, though they are not aggregated) and inject them into the loaded iFrame also. While this does mean another HTML page being rendered, all the CSS that is on the parent page will almost certainly be cached by the browser and thus not need to be retrieved from the server again.

Then again... the issue of "context" gets messy, if a body field had 20 wrapper DIVs and parent classes, you'd need those to be present also so that selectors worked properly. But you wouldn't want the layout/padding of those parents... and so you'd be totally hosed. Without the parent wrappers you end up with the oh-so-common problem of the site theme's "body" tag (which has a background image or color) being used as the background of the editor.

The interesting thing about this issue and the issue over in the WYSIWYG in Core project (#1260052: Candidate WYSIWYG editors), is that they're actually slightly at odds. When it comes to the node form, you don't exactly want inline editing because the node form is usually displayed in the Admin theme. You'd want the node form to use CSS relatively similar to the front-end of the site (similar font families and sizes perhaps). Though with targeted CSS, you could probably make an inline editor like Aloha have an appropriate appearance, though the floating toolbar again is awkward in a node form situation.

So basically I'm trying to figure out if the initiative to get WYSIWYG in Core has any relationship/bearing with Spark. But Spark will have to solve the node form WYSIWYG editor also, so I'm curious what approach will be used there. Aloha may be at a disadvantage on the node form, but it would seem like lunacy to include TWO editors in the project, one for front-end and one for back-end (especially if the ultimate goal is to merge into Drupal core).

I don't think iframe-based editors (read, pretty much every editor except Aloha) are entirely out of the running.

I think they are for in-place ("true wysiwyg") editing for reasons covered in the Google doc and earlier comments. Even though you can inject the CSS you want into an iframe, there's no clean generic way to make all selectors match.

Spark will have to solve the node form WYSIWYG editor also, so I'm curious what approach will be used there.

I suspect that creating an iframe wrapper, and putting Aloha into it, for node form usage, won't be that hard.

So basically I'm trying to figure out if the initiative to get WYSIWYG in Core has any relationship/bearing with Spark.

So long as Core doesn't have in-place editing, which it won't until Spark proves itself, the WYSIWYG in Core (unofficial) initiative isn't constrained to a no-iframe requirement, and without that constraint, TinyMCE and CKEditor are attractive given their maturity. However, given that there's developers who will be working on Spark, solving some of the integration issues between Drupal and the chosen editor (Aloha seems to be the current front runner) that WYSIWYG in Core wants solved (client-side filtering, image+caption grouping), perhaps that will entice the WYSIWYG in Core developers to choose the same editor, even if the editor itself is less mature than TinyMCE and CKEditor?

@quicksketch: please get in touch with Wim Leers if you haven't already (I know he's been trying to get in touch with you). He may have an opportunity to discuss the concerns about Aloha raised in this issue's comments with some of Aloha's core developers, and having your involvement in those discussions would be very appreciated.

It's easy enough to grab the tags from the parent page (or use the list in Drupal.settings.ajaxPageState.css, though they are not aggregated) and inject them into the loaded iFrame also.

Although styling is the justification here for dropping iframe-based editors, it seems like whenever people start talking about the use of iframes it's either in terms of the security of them and the way they can effectively and properly split apart a page into totally independent pieces, or in terms of coming up with (often dirty) tactics to undermine their security and make them work as intercommunicating components of a page.

So as far as in place editing goes, I'm glad Spark is opting for the former which seems like good non-use of iframes, and

creating an iframe wrapper, and putting Aloha into it, for node form usage

sounds like a better use of iframes.

#73:
- Applying CSS to iframes is indeed possible for simple cases, but as you already indicate: it's near impossible to do it perfectly when you're dealing with complex structures/complex CSS selectors.
- Regarding the floating toolbar: nothing has been decided in that area yet; it's perfectly possible to alter Aloha Editor's current toolbar behavior, or to override it with another UI, that better matches our needs/vision.
- At the moment, Spark is really focusing on the "inline editing" aspect (as indicated by http://buytaert.net/spark-update-in-line-editing-in-drupal). So, to some degree, it's a problem we're not dealing with right now. But of course, it's something we'll need to solve as well. Naturally, we'd love to achieve synergy here instead of having two efforts that cannot be reconciled.
So, I have an idea. We're touching three problem spaces:

  1. The "preview" problem. (Which really consists of two subproblems: A) the styling of the preview does not match the eventual styling, B) the display of the node in its eventual context, i.e. how it will show up on a page with blocks etc. surrounding it.)
  2. The "WYSIWYG" problem. However, there's WYSIWYG on the front-end (A) and back-end (B). (As you eloquently described in your DrupalCon London talk, e.g. image captions + aligning the image/caption pair is near impossible to achieve in Drupal, etc.; summarized: WYSIWYG in Drupal is limping in comparison with e.g. Wordpress.)
  3. The "inline editing" problem. Which Drupal does not do at all yet.

From what I can tell, WYSIWYG in Core tries to solve 2.B, maybe also 1.A; Spark currently tries to solve 2.A and 3 (but will eventually also have to deal with 1.A and 2.B). 1.B requires significant re-architecting of Drupal's "node edit/view system", which is why it's out of scope for both projects.
Now, it is possible to do "true WYSIWYG" on the front-end (2.A). But it's near impossible to do "true WYSIWYG" on the back-end. So, what if we flip things around? Instead of using an iframe-based editor on the front-end (2.A) — which would require us to inject CSS into an iframe and never get perfect results easily, we use something like Aloha Editor (which does not need the CSS injections) on the front-end (2.A), but also use it on the back-end (2.B). Hence we'd stop using a textarea on the back-end (and possibly add some CSS there, because we can never achieve perfect styling on the back-end anyway). That way, we can use the same WYSIWYG editor everywhere.
(This would of course not apply to text that cannot be edited with Aloha Editor, such as Markdown/Textile/…)

I hope this all makes sense. It's a thought that crossed my mind while I was reading your comment, so hopefully it's not too crazy. Looking forward to your feedback :)

#74:
- adding an iframe on the node edit form with the body text and Aloha Editor is an interesting way to achieve the above. But it won't allow us to reuse the same stylesheets unless we still reproduce the same "context" (as quicksketch said; same nesting of divs etc.).

On 1B, and feeding into all points:

One solution is to stop offering frontend-themed WYSIWYG on textareas on the backend nodeform at all, given that it results in an inadequate representation of the outcome (for example, the unstyled title field). Plus semantically, all that should be needed on say the body field on the nodeform is an indication of whether a user is defining a piece of text as 'heading 1', 'paragraph' etc... to give them WYSIWYG control just tempts users to try and manipulate a site's styling control against it's will and to their liking.

The currrent 'preview' workflow is better in my mind, because once a user has 'structured' their node with field data entry and by applying semantically appropriate tags to text -> they then click preview, and they can then do inline editing before final submission, and have all the blocks etc. surrounding their node while they do so, with all their field data represented on the page in all it's glory.

So I would say, let the admin theme stylesheets handle textareas on the nodeform. It doesn't matter how it 'looks' (i.e. the body field's job isn't to show how a node will eventually look), it's just a little bit more user-friendly than having a presentation like <h2>I'm a H2 heading</h2> to indicate how a user has categorised a piece of text.

Plus semantically, all that should be needed on say the body field on the nodeform is an indication of whether a user is defining a piece of text as 'heading 1', 'paragraph' etc... to give them WYSIWYG control just tempts users to try and manipulate a site's styling control against it's will and to their liking.

Users demand it, though. I've yet to meet a nontechnical user who was able to get comfortable with the idea of mentally interpolating semantics to structure. Plus, this doesn't really address the problem of formatting things like aligned images with wrapping, formatted text callouts, CSS-rendered shadows, etc. Users demand the ability to see those things and they're unhappy with the experience (and the product we build for them) if they don't get it.

So, sure, semantic rendering ought to be enough -- but it's not.

Huge ++ on #77. Semantics on the back end and in place editing on the front end is a fantastic way to frame content editing.

#80: it's a fantastic way to alienate non-technical users. You just can't assume that you'll be able to ghettoize them all into edit-in-place scenarios. It's not going to happen. They want WYSIWYG and if they don't get it, they'll see it as a defect in the system. And they'll be right.

@escoles I'm not sure I see that... I think non-technical users just want an easy life, they don't want to feel that somehow they're responsible for designing a website, the more it looks that way the more they'll shy away for fear of embarrassing themselves. In general I think non-technical users would prefer the methodology in #77, they just want to be told what to do, and for the way of doing it to be simple and intuitive.

It's certain semi-technical users who will get annoyed that they can't have absolute control of the look of their website like they can on Dreamweaver or Frontpage... and they'll probably go back to that, because I don't think Drupal is moving that way even in terms of IPE, it's just making, as I said, semantic editing simpler and more intuitive.

I don't think trying to get the right styles into fields on the node form will ever consistently be useful WYSIWYG, in tons of cases it would be totally unfaithful. Example: I have a rich textarea that's styled differently in 7 different contexts across the site - which style do I choose for the node form? Fields on the node form are just data and have no rendered life until they're submitted and the site decides what to do with them, including how that data looks in different places.

If I was a site designer that wanted a simple static page site and didn't want users to edit in the admin theme, I would probably design some interface for creating stub pages, therefore bypassing the node form, and the user could edit them in place.

I'm in something of a position to tell you what non-technical users want because I build websites for them. You're right, they don't want to design a website -- but they are responsible for creating or editing web pages that have formatting on them, and they get irritated, unhappy, tense, uptight, sometimes alarmed, when the page looks different from what they expect, either when they're editing it or after they submit the edit form. They don't like the idea that they have to make a mental game out of saying "well this is a HEADING 2 so it will look like my HEADING 2 does on the regular page."

This is not a semi-technical user issue, it's an "assistant marketing director who has to manage the corporate website" issue. It's also a "chief creative officer who doesn't understand why she has to publish the page before she can see what it actually looks like" issue. You and I can sit here all day and decry these people's lack of a certain kind of imagination, but they are not going to change the way they think to match the way we do.

I've been very successful educating my users (technical and non alike) why they need to think that way and providing them with positive results when they do. And the more we work with responsive, the more I see semantic content creation with custom classes for what is floated above one breakpoint, or what is a callout, as being the only way for clients to enter comeplex content and have it behave well. If clients want the type of site I build they are generally happy and willing to adopt the content editing workflow that it requires.

I wasn't suggesting that non technical users only edit on the front end, but that they enter content on the back semantically and edit for convienience on the front, which has worked fine for me. I hear you though, the reality for some drupal projects may be the demand for a ms word wysiwyg layout tool. Let's consider both use cases while making a system wide editor decision.

they get irritated, unhappy, tense, uptight, sometimes alarmed, when the page looks different from what they expect

I do know what you mean, it's sort of difficult to get people used to the idea that formatting in this context is a bit like working with fields in the rest of the form... I.e. text in a H1 tag is bit like a field that's not worth making an actual field on the node form, and that the appearance you're giving it is not necessarily static as it might be in MS Word, it's an identifier.

There's always the possibility that fields a site admin sets as important to be edited 'visually' can be omitted from the node form, and dealt with in the 'preview' stage (call the workflow what you like). see http://drupal.org/node/1510544

Such that basically, all the 'backend' bits and pieces like 'dates', numeric fields etc., maybe even a few rich textareas that aren't visually critical (maybe we only have 'italic' and 'bold' enabled in these anyway) are dealt with on the node form. That way, when they get to the stage of the visual in place editing, they will have true wysiwyg.

If you don't carry the content style into the WYSIWYG when editing, all above will hear from clients:

"Why doesn't it look like X when I type in Y?"

Guaranteed. If they enter some text, highlight it and click H2, it would need to look just the way it will on the corresponding themed display. Otherwise, they get confused.

So, you either need to get CSS support in 100% in the box, or have an intuitive preview workflow (preferably something you can see happen as you type, instead of on another page).

Technical people do not mind this, but the non technical folks will get frustrated quick.

Plus when they submit, currently the node will often always look different to what they expect, anyway. For example, some date field that adds various graphics to the node, you know, different settings the user activates that change the nature of the outcome page. So above may actually be a more faithful way of doing wysiwyg, and users will be less frustrated.

Let's remember that we all have different experiences with our clientele, and our users don't represent Drupal users as a whole. There isn't a monolithic, single persona "Drupal Users", and discussion needs to reflect that. Any decisions we make, especially with large contrib projects and Drupal core, should support the common needs of as many use cases as possible, with extensibility built in for the specific workflows of the many businesses, clients, and users who use Drupal.

For the benefit of anybody following this thread, I've tried to put together a summary of our opinions as pros and cons on abandoning trying to style textareas in the nodeform with the site theme:

Pros

  • Not true wysiwyg anyway, eg.
    • Fields in a node that change the textarea’s appearance
    • Multiple themes on a site, which style to choose
    • Textarea styled different in different contexts on a site, which style to choose
  • Adding content, not creating design
  • Reinforces semantics
  • Prevents uglifying the node form with clashing styles
  • User friendly

Cons

  • Users like WYSIWYG the way it is, will see absence as a defect
  • Frustration that outcome page looks different to expected
  • Awkward workflow if some content is input in a separate (preview etc) stage
  • Some users won’t understand semantics, they’ve been taught different, won't make sense
  • Not user friendly

Just joking with user friendly in both ;-)

For contrast to 83 and 86: My clients get CKEditor with black on white, almost pure user agent CSS. I have block boxes enabled (kind of like wysiwym editor), and strip all content to plain text on paste. I think if what I gave them was close, but not exactly like what they see on the front they would be very confused, but since it is clearly different no one has a problem. And if I'm doing something fun on the front end, interactive with a lot of js (or to a lesser extent responsive) there's no way any back end wysiwyg could give an accurate representation of what will appear on the front. Clients know they are adding content, not creating design.

I am not saying that this is the only way to add or manage content, but it is a valid way, and many shops employ in the real world. So yeah, what I said in 88.

I think if what I gave them was close, but not exactly like what they see on the front they would be very confused, but since it is clearly different no one has a problem

Good point that... and I added that 'Adding content, not creating design' to #89

Note that you can edit the issue node itself to add summary data like that; that's normally where people will look for such summary info, not comment #89. :)

I'm not sure I dare, the power might go to my head :D

@lightsurge,

Thank for the summary.

Frustration that outcome page looks different to expected

It's not true. You can use same theme for editing and load same stylesheet into iframe editors. (but have performance issue)

You can use the front end theme in the editor iframe, but this doesn't mean that what you see in the editor will match the output. The most common example is floating an image -- in the full browser width editor, the line length may look good and the image lines up to a paragraph nicely, but the output shares the window length with a sidebar making the line length very short, and the paragraphs flow around differently. As I mentioned, responsive design can and will change content's appearance. It will. It redefines the editor's interaction with the content -- they're not laying things out on a 960px canvas, they're adding content with structure and trusting their designer to make good layout and design decisions across a range of device sizes and abilities.

Inline or front end editing addresses the "how things actually look" use case, by allowing actual in situ editing. Very sweet, I am totally into the idea for touch ups and quick changes. In my workflow, semantic content creation and big-picture editing on the back end is the other half of the equation.

Another reference: Wordpress uses an admin theme, not the front end theme, in their tinymce editor iframe.

@droplet #94 that was a con of getting rid of the site styling in nodeform textareas, not keeping it.

As RobW says, there are tons of cases where what content looks like in an iframe with theme styling won't be faithful to how it looks in its eventual real-site context(s).

Including from #89:

  • Fields in a node that change the textarea’s appearance [in the theme, after the node is submitted and is now being viewed, eg. a tag that gives the node a background image, a date that adds fancy calendar-style graphic within the node etc etc]
  • Multiple themes on a site, which style to choose [what if I have 10 themes on my site that users can choose from, which should I put in my content creator's nodeform textareas, the most popular theme?]
  • Textarea styled different in different contexts on a site, which style to choose

Really we're only giving the content creator a vague idea of how their text might look somewhere on the site, if viewers happen to be using the same theme as the content creator. In many cases surely they get just as good an idea from looking at their site in the first place, an idea of the theme and how it looks and how it styles stuff.

If we stick the theme in the nodeform textareas and right in front of them they get a 'sort of' impression of how their theme mightstyle it, as robw says, a content creator new to the site still has to second guess how the theme and site might treat their input responsively, and they still have absolutely no idea what the node will look like when submitted and all the other field-based stuff gets stuck around it.

Re, the approach RobW suggests @90, I've been trying that for years and have had very limited success. Some get it, some are willing to work with it, most don't/aren't. I personally think it's important to understand the page semantically; most users of we web think that's just a bunch of geek nonsense they shouldn't have to worry about. As I've said, I think in structure, but I happen to agree with them -- they shouldn't have to worry about it.

As for educating users, that's arguably (but only arguably) fine as long as you're talking about one generation of users -- what happens with the second-generation users, when new users start to come online that you don't get [paid] to train? That's the point where some intern in their marketing department pipes up and says 'they don't know what they're doing because if they'd built it in wordpress you wouldn't have to do it this way.' Forget for a moment that the kid is wrong and remember that he's both more-proximate and younger than we are, so when they're irritated with us for not giving them what they expect, they'll believe him.

The thing that's really important to be able to get right is stuff like image styling. We must, must, must be able to code styles for the edit field, if only to cope with special formatting cases applied by styles. Here's an example: We define image styles so that images can be forced to float left or right with certain guaranteed spacing (and in more recent cases, CSS drop-shadows) around them. In CKEditor we have them do this by just selecting a style from the styles drop-down. It's acutally hard enough to get people to do that instead of selecting size or color from the toolbar. [we take those out of the toolbar so they can't choose them, but some of those clever college kids just go into source mode and hard-code them anyway -- see 'second generation users', above.]

See here for a simple example -- image left-aligned, with text wrapping, margins guaranteed, all done in a way that's easy to make it work in a WYSIWYG editor:
http://sandlotsolutions.com/who-we-serve/patients

Another example: We code predefined styles for things like callouts, emphasized text, and captions -- e.g., see middle of the page here for an emphasized text passage:
http://stonebridgebp.com/compliance-auditing

Here's a test page that happens to illustrate callout, emphasized text, quote, and right-aligned image (the other stuff on the page is mostly containers without class attributes, but those are from our pre-defined style classes):
http://sandlotsolutions.com/layout-test-page

All of that having been said, and more to the point: You guys seem to me to be throwing away the baby with the bathwater. Your reasoning seems to be "if it can't be perfectly WYSIWYG, it's not worth doing."

I'm not arguing that users expect perfect WYSIWYG. In fact, I don't think they'd know it if they saw it. But they do want and expect and deserve to get something close.

@escoles http://sandlotsolutions.com/who-we-serve/patients

This sort of website looks exactly the sort (I may be wrong, I don't know the innards!) that could have it's UX much improved by a Spark that doesn't bother at all with nodeforms in certain cases.

For example, rather than going to node/add, we click a button saying 'Create a page within who-we-serve', which programatically creates a draft node pre-filling all backend fields (menu etc), with placeholder text for the title and body, and then the content editor edits this node using the in place editor (with Aloha, wysihtml5, whatever), and it's properly faithful wysiwyg. Then publishes it.

One of your sites? Very nice.

Btw I don't necessarily mean get rid of the nodeform entirely (altho surely that'd be nice if possible), just a sort of change of workflow, any tidbits of backend configuration could be done after/before our content editors are satisfied with how the node looks on the page.

Spark being a distribution it might even be feasible to incorporate such a feature set, which could be disabled by site designers whose content will be very much field-based and it's just not about straight page-building.

I'd love that, I've been trying to help with http://drupal.org/project/julio a distribution that's very much about just straight page building, and Spark's in place editor could be awesome there.

Escoles, looking at your examples, those are perfect cases for the WYS is pretty damn close to WYG on node edit pages that we have now. They use simple, generalized styling that is consistent across the page regions and site. When you get more complex things can start to fall apart, but that doesn't mean that your workflow shouldn't be an option. I absolutely think it should.

I'm not sure exactly what we're discussing anymore, so let's try to rein it back in. I'm going to start calling the admin theme side "admin end" to avoid confusion.

We have established:

  • Front end editing is the only way to show true WYSIWYG, since you are editing content in the actual context it appears in.
  • Admin end editing can't show a true representation of what you get on the front in all cases, re: repurposed content, complex themes, user configurable theme choice, widgets, js manipulation, etc.
  • Admin end editing benefits from configurable css, whether a developer chooses to use front end theme css or semantic accentuating css. Neither should be the only option -- that would break the Drupal editing experience for the non-chosen side.

Where do people want to go with this?

@Wim Leers (#76) - I think having the same editor in the front end and back end should be a requirement. Aloha would work good for this, especially since you do have the option of setting the toolbar to be top aligned (or even bottom). Hopefully they can get the size problem handled, as I see that being the only real issue. I think if they get rid of a lot of the redundant range API and use jQuery to handle the santizing, they will chop off quiet a bit.

On the backend, something I was just putting together in my head only was the possibility of letting the node template output the form. This would most likely require some changes to the field API and FAPI, but the basic idea is when things like $title are printed, it outputs the title field/editable div. Same thing on $submiitted. It would print the current author and date, but when you click on it it would expand to allow editing of those items and contract when that area loses focus.

Actually thinking further, this could possibly be done with pure JS, leaving the form intact for fallback. The node template is injected into the top of the form purely as placeholders that JS uses to move form elements too. Then you would end up getting a more real visualization of what you are authoring.

I actually really like the idea of scaling back the admin-end "WYSI mostly WYG kinda" approach and focusing on an entirely front-end editing approach for that. I think it becomes an uncanny valley problem, really. And let's also recall that in D7 and D8 many sites use Overlay for node add/edit screens, which is yet another layer of complication and Inception.

pseudo-WYSIWYG is what Wordpress uses, sure. And it's what most fancy CMSes have used for the past decade. That was then, this is now. :-) If our guideline is "be like Wordpress", then Drupal will be a Wordpress also-ran. That's not what it is now, nor should we let it become one. If Wordpress uses a pseudo-WYSIWYG, let's trump it with viable real-in-place-editing. Don't view it as "users won't expect that"; view it as a Drupal-awesome feature that makes us a market leader.

Incidentally, Symfony CMF (which I think is a better competitor comparison, or will be in the 24-month timeframe) is also using mostly-front-end editing using CreateJS.

So I'm totally down for edit forms that have (optional) code-assistance tools, even if they're WYSIWYG-esque, but saying up front "no, this is not an InDesign window, it's not going to be, we're not going to try and make it one". That's where you can just bang out a blog post where all you want is a couple of bullets, some line breaks, add a couple of links, etc.

For a fancier experience, we have (again, optional) in-place-editing on the front end via Aloha or whatever. Trick that out experience and funnel the "I wish this were Word but I'll settle for this" users to that.

Then as site builders, we can enable neither, one, or both of those tools, per field, as is appropriate for our particular user base.

The punk intern who only knows Wordpress and so blames Drupal for not being like Wordpress doesn't carry much weight with me. The way to shut him down isn't to make Drupal more like Wordpress; it's to make Drupal that much better than Wordpress so that his boss tells him to shut up and go make more coffee. :-)

(Disclaimer: No offense intended to non-coffee-making and non-punk interns, of whom there are many.)

Since no one has yet brought up the guaranteed-to-rain-on-the-parade-licensing-discussion yet, I have to wonder if Drupal is compatible with Aloha's license, which is AGPL 3.0. It's basically like the GPL but has the effect of "infecting" software on the server. Basically if you used Aloha on your site, any JS that interacted with Aloha would need to be publicly downloadable (and not compressed or obfuscated in any way). I'm not sure if this is inline with Drupal's licensing philosophy. The normal GPL only infects other software if you make it a distribution (such as Spark), but this could have an impact on the users of Drupal or any SaaS site (like Gardens).

A good example of repercussions of this might be Acquia's theme designer on Gardens. If they used Aloha in it, they would be legally required to provide a downloadable copy of the theme designer's JavaScript code (which I think is still proprietary based on this discussion). That's quite a departure from the normal GPL, which doesn't have this requirement when dealing with server-based software. The overview of the AGPL is here: http://www.gnu.org/licenses/why-affero-gpl.html

Yeah, in terms of licensing, AGPLv3 is out, but http://aloha-editor.org/license.php outlines a way to get a FOSS license exception for something like Drupal. We're planning to have a call with their team sometime in the next couple of weeks to hash out stuff like that, as well as some of these other architectural questions. Please keep them coming!

Now we're basically discussing how to deal with WYSIWYG on front-end (in-line) vs. back-end (the node/add form, and also node/edit). For consistency and to be more welcoming to non-technical users, we need to be able to offer 1) the same WYSIWYG editor on front- and back-end, 2) the styling needs to be identical. Point 2 is extremely hard. I would even say: nigh impossible (as #82 proves).
So … I think the only way to have a consistent WYSIWYG experience (on front- and back-end) is to essentially have an absolutely minimal back-end whenever WYSIWYG is used: only "meta" information is shown on the back-end, all "visible" information of the content is edited on the front-end. Or a different criterium could be: add/edit "visually dominating content" on the front-end, in the sense that you have to see it in its eventual form to be able to edit it well. I also think that's the biggest reason for content creators to (rightfully) complain about this?
Tricky things here are, a.o.: knowing which fields are not displayed may be impossible due to template file overrides (hence: explicit theme system support needed); fields that are very strongly themed (in that they're transformed to such an advanced piece of HTML/CSS/JS); unless we force the user to manually select which fields are available for editing on the front-end, of course.
Thoughts?


#77/#78/#80: Essentially, this is structure vs. WYSIWYG. I prefer structure overall, and WYSIWYG for quick edits. Yet many don't know, nor want to deal with anything that's not WYSIWYG. As @escoles already said in #79/#81.

#82: good point! A "article" node may have different CSS applied to it depending on the context. But in that case, why don't we still use a WYSIWYG and just use the admin theme's CSS instead of somehow magically inserting the "eventual" CSS?

#83: see #82, plus: the user is trained to know that on the node/add form (back-end), it won't look exactly like it'll look on the eventual page (front-end). But thanks to our inline editing, the user can make changes to make it look exactly as (s)he wants?

#84: Exactly! "Back-end: semantics; front-end: convenience." That's in my reply to #83, but you said it much better :)

#89: Thanks for the summary!

#90: Excellent point. This also is much more feasible. Also thanks for the Wordpress reference in #95.

#97: Indeed; even if we succeed in applying the same CSS rules to the "back-end WYSIWYG", it will never be in the same context, so the width won't be identical, etc.

#98: Very, very valuable feedback. I hadn't thought about the need for the WYSIWYG to support "site styles" or whatever you call them, so e.g. a <p class="callout" />. I think this is essential for empowering site builders to empower content creators.

#104:
-

If Wordpress uses a pseudo-WYSIWYG, let's trump it with viable real-in-place-editing. Don't view it as "users won't expect that"; view it as a Drupal-awesome feature that makes us a market leader.

+999999999!
This is what I wrote on May 17, 2012, in my "Spark goals" document that I created on my third day at Acquia, after having been introduced to the Spark designs:

One-up Wordpress in UX!

This is the right time. Wordpress seems to be "stuck" in its current paradigm. To be fair, I think it works well for Wordpress — probably because of Wordpress' simplicity? (Which is a good thing, not a bad thing, but it can't work for the hyper-modular Drupal.)
- Is Symfony CMF + CreateJS a fact? Will they use CreateJS with Hallo? Does that imply they consider Hallo sufficiently mature?
- I'm very curious to hear what you think of my idea at the beginning of this comment.

#105: They'll likely give us a GPLv2 license :)


At the moment, I see two viable paths:
1) WYSIWYG only on front-end; WYSIWYG'd fields are not available on the back-end
2) WYSIWYG on both front- and back-end, but the one on the back-end falls back to "obviously not the eventual styling" styles

But in that case, why don't we still use a WYSIWYG and just use the admin theme's CSS instead of somehow magically inserting the "eventual" CSS?

Unless I'm misunderstanding you, that's actually what I meant, and was the start of this topic of discussion (which to be fair has spiralled out a lot!), that the admin theme could just give some semantic indication of formatting in the nodeform wysiwyg.

So I would say, let the admin theme stylesheets handle textareas on the nodeform. It doesn't matter how it 'looks' (i.e. the body field's job isn't to show how a node will eventually look), it's just a little bit more user-friendly than having a presentation like <h2>I'm a H2 heading</h2> [like on drupal.org] to indicate how a user has categorised a piece of text.

#77

Another thought just occurred to me, IPE will have implication for modules that manipulate stored text for display.

Take for example http://drupal.org/project/extlink which I think (if I remember correctly) wraps a span around links, that would end up being editable in IPE and replicated on store, no?

I'm also a little concerned about anything that runs through text format filters like Token filter or Media. If the user changes the output of the rendered, final text, then it's going to be impossible to retain the raw data when you edit the node via node/%node/edit since it would have been replaced. This is bad for example, for Media usage tracking that needs to attempt to stay accurate whenever a media item is used.

Glossary module too, and any module that tries pretty up a block of text with semantic linking (I'm getting sick of the word semantic now, I've over-used it so much I think I've forgotten what it means!), cross-referencing, etc. For dozens of reasons including these, security for example, Drupal does pretty much all it's work on user input on output, and that's going to make IPE difficult. I can't even imagine a solution really apart from Spark doing some sort of comparison of the filtered output that it just rendered, and the changes a user makes - eliminating any stuff that it looks like the input format handled. Better still, if the input formatters added some identifier to the stuff it puts in.

We can probably forget about any changes modules make in javascript, that's a no fix surely and something those module maintainers to fix if they want to (again by perhaps adding a class that IPE ignores).

Better still, if the input formatters added some identifier to the stuff it puts in.

@Dave Reid I suppose in your examples as well as an identifier those tokens would have to be put in as well, so that Drupal knows to save that rather than the markup (otherwise we'd have to have some kind of comparison of database stored field, filtered output, and user edited markup which borders on artificial intelligence!).

Is artificial intelligence out of scope for the Spark project? :)

@DaveReid if you could do a diff on how the edited content is changed that might be one way to deal with tokenized or filtered content.

It seems to me you'd want to pull the field values from the DB for inline editing, and in the case of something like Media run the tokens through the same wysiwyg js that's we currently used on the admin end. The downside is that it can't be exact WYSIWYG, but maybe it's close enough, especially if the other option is overwriting tokens with processed/rendered output. And we hope that eventually, possibly depending on the WYSIWYG that is chosen, workarounds like Media WYSIWYG placeholders won't be necessary.

@107: Your idea in 2. is interesting, but I don't think it works. Drupal is content centric, and a full overview of the content is essential when you're really using the strengths of this type of system. I always go back to this same example, but I think it illustrates the point well: on a newspaper site you will have the article body, multiple names and teasers (a title, a slug, a one line intro, a short summary, etc.), and multiple supporting fields (images, taxonomy, metadata, etc). If you change one of these fields you may need to edit multiple, and refer to each as you edit. And all of them will never be output together in one place on the final site. The layout is taken care of already by designers and developers who set up the system, and the site users only care about adding and managing content efficiently. This is one of the main strengths of Drupal, what makes it better than Wordpress especially: real content centric content management.

IMO, on sites like these that leverage Drupal's serious CMS muscles, the admin side will always be the primary way users interact with content. IPE is a great tool to add on top of that, for fixes or layout polishing or as primary editing on a different type of site, but can't be a replacement.

RobW: Agreed entirely. I think we're all on the same page that the "traditional" editing approach will not and cannot go away; this is adding an alternate approach for those use cases that can support it, which in turn looks like it may allow us to stop trying to bend over backward to merge front end/back end editing via a "WYSI mostly WYG" editor.

Another module to add to the "alters output" list: Views. If you're editing a field that is reduced to X hundred characters by a view, do you have access to the whole field on IPE, or just the X hundred characters? Or, if your're rewriting a field on a view with tokens of other fields in the view, will we be able to add IPE to the final output?

We should probably take these questions on context of editing to #1494628: Add inline editing to Spark and leave this issue sorely about choice of WYSIWYG.

looks good. no support for RTL languages like Arabic and Farsi though

@ #114 That's what I was thinking, and add some html comments to explain to IPE what it's saving as opposed to what it's displaying.

Sounds like its easier to figure out what works best in the admin area first and work outward from there. As #117 points out, probably a good bit of users out there using Panels/Views/Display Suite etc - how does it react then?

@Crell, that would be the best Drupal win.
@Dave Reid, eh sorry about that. Back on track.

@#115 'html comments'? Not sure what you mean there, could you explain a bit?

I was envisaging
1. generating a diff in js between content-before-edit vs content-after-edit
2. post that diff up to the server
3. the server applies that diff to the field

We already do some stuff in the aloha module where in the js we strip out content that's been added to the field html but that doesn't come from the saved field in the database.

I was thinking do a diff after token_replace and stick the token in comments, alongside the markup that shouldn't be saved

Just to explain my meaning a bit better. If we could do a diff after the input filters run token_replace (* see note), we could replace each instance of those replaced tokens with something like:

<!--TOKEN-STARTED="[token]"-->
<h2>I'll be your token output for today!</h2>
<!--TOKEN-ENDED-->

So Aloha can display the markup but the containing element also contains the hidden token. Then on hook_node_update take out the markup and replace it with the actual token.

The advantage of this method might be that it could help in terms of developing plugins. For example, we could have a button on Aloha that allows to change attributes of a Media token, so that for example we could alter alignment, change imagecache styles, etc.

* Problem is this is me being a bit overly presumptive assuming that there's hooks available that will allow us to do this, because I've never done it before.

That's a pretty clever solution, but adds code bloat that doesn't play well with mobile or slow connections. Not sure it works for a mobile focused Drupal 8.

Lots of good thoughts here, but let's move implementation discussion to a new thread, and leave this one to which wysiwyg is best for spark (wysihtml5! I'm still carrying the torch).

@RobW No code bloat at all, all server side PHP? Apart from any plugins that might take advantage of the new info available to the editor. (edit: ahh I think the plugin side was what you meant, but that would be optional in place editor features for the consideration of the site owner?).

Aren't you suggesting outputting comments in the HTML around the rendered token?

@125 - I actually created #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up a few days ago with this situation in mind. Here's a good example. You have a custom image/caption plugin. It does markup something like:

[image fid="123" title="my image" align="right"]This is my caption[/image]

When that runs through the input filter it gets transformed into:

<div class="myimage-class myimage-float-right"><img src="http://example.com/img.jpg" alt="my image" /><div class="imgcaption">This is my caption</div></div>

If you do inplace editing of the filtered content and say someone changes the caption. Well once it goes through filtering again, then that caption would either get stripped or the changes not propagate.

In that issue I propose coming up with a base syntax for custom markup in Drupal, where we can have a universal plugin inside of Aloha (or whatever is chosen) that sees those tags, renders a visual representation and then allows editing of that tag's attributes, settings, etc. through the interface. That plugin would further offer it's own API to allow additional modules to easily add new custom tags without having to author a full blown plugin.

That means the workflow for doing an inline edit on the code side would be:

  • Original content loaded from Drupal with some filtering occurring to protect from XSS.
  • Editor is instantiated, replacing custom markup with the proper representations.

Upon saving:

  • Custom markup placeholders returned to custom markup
  • Post sent through final filtering.

This would also help with times that Javascript is inserted into a post intentionally (some embed videos, polldaddy, inline ads, etc.). A custom script tag and placeholder could be created to handle just that.

Aren't you suggesting outputting comments in the HTML around the rendered token?

Yeah but surely that's just a bit of extra markup that the browsers won't even do anything with other than download. The html comments would pretty much only contain a token, it wouldn't be likely to be a lot of text.

@#125 That looks like it would work. Couldn't you just implement it as an input filter which get's run before the other input filters?

Couldn't you just implement it as an input filter which get's run before the other input filters?

Agreed for many cases that would make it very simple... we could escape the tokens in the html comments so they don't get altered by subsequent filters.

But in the case of the glossary module, all that it looks for is taxonomy term names in the body, and replaces it with links to the taxonomy term page. So for that use case the html comments might look like:

<!--REMOVE-HTMLTAGS-FROM-THIS-TEXT-->
<a href="i-found-related-nodes" title="I know what you're thinking, and I can supply more information!">I'm a term</a>
<!--ALL-DONE-->

or

<!==JUST-REPLACE-THIS-WITH="I'm a term"-->
<a href="i-found-related-nodes" title="I know what you're thinking, and I can supply more information!">I'm a term</a>
<!--ALL-DONE-->

@#132 Ah yes, it would only work for tokens, other filters (extreme eg http://drupal.org/project/pirate) would need a different approach.

Another problem is in the latter case (not the token case) we'll end up having to put sanitised text back into the DB or put unsanitised text into the html comments.

i.e.

<!==JUST-REPLACE-THIS-WITH="I'm going to XSS you, because I'm being viewed in In Place Editing, and my evilness must be recorded... so I can probably even undo this html comment and blast you right now!"-->
<a href="i-found-related-nodes" title="I know what you're thinking, and I can supply more information!">Unfortunately, in this particularly tag, I've been made safe, and a little embarrassed</a>
<!--ALL-DONE-->

@ #134 I would actually just say go ahead and just accept sanitised markup back into the DB, to be fair an editor like AE might sanitise nasty markup input and Drupal would never know about it anyway, but perhaps there's security reasons that Drupal would want to try to keep evidence of, for example, someone's attempts at XSS on the nodeform.

We really need a much more robust system than the simple tokens, which is what I proposed in #129

Here's a not so extreme case, the Advertisement module, which shows over 8,000 installs. In that module you can manually place ads within your content by adding the [[add]] tag. That is then replaced with the appropriate javascript when it is filtered. Aloha doesn't play well with Javascript inside a contentEditable area. Actually most WYSIWYGs don't, unless you have some sort of placeholders system running.

Here's an example I just ran using Aloha and putting a polldaddy poll in the test. My original code in the editable area:

<script type="text/javascript" charset="utf-8" src="http://static.polldaddy.com/p/4390303.js"></script>
<noscript><a href="http://polldaddy.com/poll/4390303/">test</a></noscript>

Now run Aloha's getContents() on it and here is what you get back:

<a style=""></a><div class="PDS_Poll" id="PDI_container4390303"><div id="PDI_form4390303"><div class="pds-box"><div class="pds-box-outer"><div class="pds-box-inner"><div class="pds-box-top"><div class="pds-question"><div class="pds-question-outer"><div class="pds-question-inner"><div class="pds-question-top"> test</div></div></div></div><div class="pds-answer"><span><span class="pds-answer-group"><span class="pds-answer-input"></span><span class="pds-answer-span">a1</span><span class="pds-clear"></span><br></span><span class="pds-answer-group"><span class="pds-answer-input"></span><span class="pds-answer-span">a1</span><span class="pds-clear"></span><br></span></span></div><div class="pds-vote"><div class="pds-votebutton-outer"><a class="pds-vote-button" id="pd-vote-button4390303"><span>Vote</span></a><span class="pds-links"><a class="pds-view-results">View Results</a><br><a class="a2a_dd pds-share" href="http://www.addtoany.com/share_save#url=http%3A%2F%2Faloha.dev%2Ftest.html%23pd_a_4390303&amp;title=Poll%3A%20test&amp;description=">Share This</a><a class="pds-pd-link" href="http://polldaddy.com/signup-free/?ad=poll-front">Polldaddy.com</a><span class="pds-clear"></span></span><span class="pds-clear"></span></div></div></div></div></div></div></div><img src="http://pixel.quantserve.com/pixel?a.1=p-18-mFEk4J448M&amp;a.2=p-ab3gTb8xb3dLg&amp;labels.1=type.polldaddy.poll" alt="Quantcast" height="1" width="1"></div><div id="PD_superContainer"><div id="SwfStore_swfstore_0"><object> </object></div></div> &lt;a href="http://polldaddy.com/poll/4390303/"&gt;test&lt;/a&gt;

Which of course makes sense since this is now part of the DOM you are editing. The token idea is good, but we really need something far more advanced to handle these type things.

IMHO this should really become a separate Spark issue, as this is going to need to be considered regardless of what editor is chosen.

@#136 That would actually work with the proposed token system wouldn't it? Everything between the comments would be stripped and replaced with the original token.

Edit: agree this discussion should go in a separate issue.

@Jamie Holly

Still got to get my head around your proposal ;-) Will post after.

this should really become a separate Spark issue

I would agree but there is a wysiwyg 'plugin' aspect here that's firmly related to this and perhaps that will help people chime in and make their views, to help make a decision here.

#137 - It would, but the big problem is how the preprocessor would know when to insert those tokens. That's why a full fledged custom markup system really needs to be considered. It's too late to do anything like that in Drupal 7, but should be in Drupal 8. Look at some of the different ways of custom tags we have in contrib now - [] [[]] >!--{whatever}--<. The list really goes on.

#138 - This issue is going to be raised regardless of what WYSIWYG editor is chosen. That's why I feel it should be a separate issue and can start getting some serious discussion there.

From #136

IMHO this should really become a separate Spark issue, as this is going to need to be considered regardless of what editor is chosen.

If is another issue already. See Add inline editing to Spark

If we do go with Aloha, it looks like the block plugin might be handy when dealing with special markup put in by filters:

http://www.alohaeditor.org/guides/plugin_block.html

Here's the demo page:

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

#109: that would not be too terribly hard to solve. The number of Drupal modules that do these kinds of client-side manipulation is very small. We could just ask them to also have the ability to revert the changes they made. In the case of extlink, this is very doable. Then, upon starting the inline edit, we would just call their revert behaviors.

#110: That's critical indeed. I'd imagine that whenever the current visitor is allowed to edit the content on the current page, it would be rendered with some additional mark-up, enabling us to provide WYSIWYG integration and to only store the proper, "pre-transform" mark-up.

#113: LOL, AI is definitely out of scope for Spark! :D

#115/#116: Agreed. So, then you agree with "2) WYSIWYG on both front- and back-end, but the one on the back-end falls back to "obviously not the eventual styling" styles"?

#117/#121: Views etc. support, where not the "full content of a field is displayed". There's only three ways to deal with this: 1) don't do anything at all, 2) don't allow IPE, but link to the full node edit page, 3) load the "full content of the field" and allow that to be edited in-place.
But as Dave Reid already said: let's discuss that in #1494628: Add inline editing to Spark.


Let's move the "transforming input filters" discussion to #1605412: Brainstorm: provide WYSIWYG [filter compatibility] and only store the proper, "pre-transform" mark-up, the "contextual inline editing aspects" to #1494628: Add inline editing to Spark and let's focus in this issue on 1) which WYSIWYG editor to use, 2) how to deal with WYSIWYG on the back-end (i.e. the node/add and node/edit forms). We need to keep the latter aspect in mind for making a decision.

Can we all agree with #115/#116, and thus choosing the following path:

WYSIWYG on both front- and back-end, but the one on the back-end falls back to "obviously not the eventual styling" styles

WYSIWYG on both front- and back-end, but the one on the back-end falls back to "obviously not the eventual styling" styles

That sounds great to me.

Same here (of course).

We'll still need a way to inject a few lines of custom css into the editor on the admin side in order to handle site-specific classes (callout, code blocks, etc.). If someone really wants to recreate a "WYS is sort of close to WYG" on the back-end, they could do it manually there.

+1 to #142.

I'm not sure to avoid iframe is a must. Because there are filters, we can't just simply directly edit the content on page, as they are not the "real" content. In any case, we have to fetch the content from server, edit it, then save and refresh (a portion) of the current page. So, I don't think we have to avoid iframe: what we see in the editor never is what it will be on the page.

@lightsurge, @RobW #96, #97:

#97: Indeed; even if we succeed in applying the same CSS rules to the "back-end WYSIWYG", it will never be in the same context, so the width won't be identical, etc.

at this point, I can only imagine negative margin/padding will given different results. (moving the contents outside the main content area).

Of course, NO doubt it's harder to do same style in iframe based editors.

symfony2 CMF demo (using contenteditable editor):
http://cmf.liip.ch/en

We had a call with the Aloha Editor developers.

It's now time to branch off this discussion into two topics:
1) *which* WYSIWYG? -> this issue
2) Aloha Editor adoption concerns? -> #1617670: Aloha Editor: adoption concerns discussion

Thank you all so much for your feedback! :)

Considering the concerns being addressed by Aloha, as outlined in #1617670: Aloha Editor: adoption concerns discussion, I give Aloha a big plus one. It seems like they are really moving forward on the project and their plugin system is really nice and a lot easier to use than the ones provided by other WYSIWYG editors.

Could we just put the contentediable attribute on the div and just write the JavaScript for the "bold" and "italics" buttons ourselves? I believe all we have to do is call a function and the browser will handle the bold button functionality for us.

@#151 - it's far more complicated than that. You got to deal with things like paste cleanup, each browser handling the enter key differently and a slew of other problems.

Ah. Didn't know that. Aloha looks promising. Maybe we should put a poll up on g.d.o.

Just found another really promising editor - no iframes:

http://www.raptor-editor.com

This editor comes with a "Raptorize" button. I don't think we even need to look further.

@#155 - Good find! Even though it's still beta, it does look very promising. Here's what I found so far:

  • Built of jQuery and UI and utilizes UI skins
  • No iFrames
  • Nice plugin architecture
  • Small (168k with all plugins - min+gzip)
  • Nice source editor
  • I do like the ability to dock the toolbar, especially to the top of the screen
  • GPL!

Things that I would like to see:

  • It has a paste cleanup but it would be nice to see that expanded. Not sure on Word clean up either
  • A better placeholders system
  • A table plugin
  • Better documentation (sure that will come in time)

It appears to be a new project, starting about 7 months ago, but it is also being actively developed. I would say this is one to take a good, hard look at.

Small (168k with all plugins - min+gzip)

Smaller than that maybe. The 'light' version, which doesn't include the 'raptorize' library (!) weighs in at 58k https://github.com/PANmedia/Raptor/blob/master/packages/raptor.light.min...

This 'light' package actually also includes the rangy library dependency, which the quoted package doesn't. https://github.com/PANmedia/Raptor/blob/master/build.light.properties

Same plugins, so I'm not sure the 100kb difference comes from apart from the 'raptorize' library. I've not looked into what it does though, unless that's the bit that sends the cartoon dinosaur across the screen - in which case I think we can all agree it's absolutely necessary to keep.

Err yes, having looked into it, it seems this 100k does in fact just come from sending a dinosaur png across the screen and making a noise... lol

I can't see this on the evaluation criteria so we can probably judge raptor editor on the 58k size unless we want to amend and include this.

At a glance, Raptor looks further along than Aloha, though I could be wrong.

It's missing something similar to aloha blocks, we need something alike to be able to support tokens and that kind of things. Making it from scratch is no fun.

I'm not sure what you mean by further along, but it's not the case on several important aspects: docs, functionalities, bugfixes are some where aloha is ahead.

@159 - yeah that could definitely be lost!

@161 -

The blocks thing isn't really all that difficult and a custom solution for Drupal might be even better. I did a similar custom solution for a client's CKEditor implementation and once you figure out certain little things, it's actually pretty easy, especially with them using Rangy (that can be used to make sure the entire block is selected and not just inner nodes).

I agree on the "further along" assessment, except for bugfixes. Currently Raptor only has 4 open issues, of which 2 are enhancements. Compare that to the 92 open issues for Aloha (only 4 for the jQuery UI milestone though). Of course that is comparing apples to oranges given how much longer Aloha has been around and the wider user base.

As far as the docs go, Aloha does have somewhat better docs (still far lacking though). One thing I think Raptor would be better at is the learning curve for developers, given it's heavy dependency on jQuery.

IMHO it might be best to reach out to the developers of Rapture and see how much they are devoting to development and how much they would be willing to work with us if we were to chose it as our defacto editor.

Yep, good points.

As someone that is relatively new to Drupal but been building websites for over 12 years, I've taken a look at the 2 options mentioned (Aloha & Raptor) and personally I would go for Raptor only because the interface looks nicer and is skinnable. I couldn't see those options for aloha, so apologies if you can.

One thing I did notice is that there are already work under way to use raptor with wordpress, personally that doesnt bother me, but I guess some people may not want to use the same tools as wordpress due to the comparisons it might cause

To be fair that issue could be marked as Fixed since we're going with Aloha ATM. I'll let Wim decide though.

We had a look at Raptor and while it's really nice might be too simple for things that can happen in Drupal :) Still, it's really a nice editor :)

Status:Active» Fixed

Yes, it's probably appropriate to mark this as "fixed". Hence I'm doing so.

We cannot evaluate options forever (as more keep appearing anyway). The choice has been made, and it's Aloha Editor.

FWIW, #164, Aloha Editor is also available for Wordpress through a plug-in: http://wordpress.org/extend/plugins/front-end-editor/.

Version:» 7.x-1.x-dev
Issue tags:+Spark sprint 0

Thanks so much for everyone's help!!

You can read more about our research and decision at http://wimleers.com/blog/spark-update-wysiwyg-choice

Assigned:Unassigned» Wim Leers

Retroactively assigning to Wim.

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

Issue summary:View changes

Adding Google Doc to the issue summary.