![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
People have been hollering for a WYSIWYG editor in core for a decade now or so. I have a vision for a limited but actually implementable version of this: the HTML5 Aloha editor in a field widget and in a text field formatter too for in place editing. In place editing is practically impossible in the generic case in Drupal as it's almost impossible to figure out what the raw version of the text is -- but for a text field, we actually have a grip. Anyone wanting to implement a node-based (we do not have entity_save) version of this for Drupal 7 can find me for mentoring the field API parts. Then, D8 core where we will have a proper entity CRUD/CRAP API.
Commenting on this Story is closed.
I haven't tried Aloha, so I can't say much about it specifically, but I think this sort of functionality would be really awesome to see in Drupal 8.
Had a quick look at the editor and must say it looks great and way more flexible than anything else I have seen.
Looks are one thing, what is more important here though is if it will work with Dries vision about that content in D8 has to be output independent so it can easily be transformed for best possible display on any device.
If Aloha editor can be configured easily so that it mark up the content that way, including being able to be customised for site specific needs, then yes it is a good candidate for Drupal Core.
/thomas
www.tsvenson.com
Oi! This would be awesome. Just looking around the Web site is amazing. The only problem is that the editor is under AGPLv3. Does the A matter?
This has been running around my mind since Bert Boerlands comment on Dries blog (HTML5 D8 post)...nice to see it highlighted here. There's also an issue for Aloha in the WYSIWYG queue:
http://drupal.org/node/1018352
I'd love to hear more specifics on your widget & formatter thoughts (I haven't looked at Rene's code, perhaps that's the direction He's taken already)
It strikes me that the one big reason for WP adoption over Drupal is WYSIWYG in the core package...not a ground breaking statement but as a site builder it's harder to sell the benefits..been said a million times I'm sure.
Cheers,
jpstrikesback
wysiwyg in core would be huge step forward, also we have to have module/drupal upgrades from the site administrators back-end. As long as you have to use SSH or (gasp) ftp we will have people disappointed with "drupal's complexity" while they will turn to WP -- or even Joomla's "ease of use"
given the massive obstacles and resistance a Wysiwyg in Core would have to overcome and face, I'd say we won't see it, if it is not made a full fledged core initiative.
Even in my small company everybody but me blankly refuses to use any Wysiwyg. Code purity and stuff are the reasons. But talk to a regular user. I have not seen one that does not completely expect some kind of formatting options in form of buttons...
"It strikes me that the one big reason" should say "It strikes me that one big reason" :)
Aloha is pretty slick and I look forward to using it and editors like it in the future. But, it's not yet ready for core. Aloha requires ECMAScript 5 which only runs in the latest browsers. IE 8 and older browsers can't use the editor. If you try to use the editor in say IE 8 you just get an error on the page and can't do anything (http://img.skitch.com/20110529-gc4gxjmcgt69gjcwihu4ju1fkt.png).
For core we are discussing if we can drop IE 6 support. There is no way we can drop IE 7/8 support yet.
I do look forward to this living on in contrib and one day being able to use these types of editors widely. Now is just not that time.
Additionally, the aloha.js file that implements this is 1 meg in size minified. It's quite large. Someone should be able to build an editor like this that's smaller. From a front end performance standpoint this is quite poor. Especially for an editor that's this large without image or other media support baked in.
Aloha Editor should work in all browsers listed here http://www.aloha-editor.org/wiki/Browser_Support . This includes IE7/8. It is true, that under some circumstances the MS browser causes a lot more challenges than other browsers do, though we are committed to support the IE7/8. We try to improve the long term quality with a http://testswarm.aloha-editor.org (Login:alohaeditor). This should help us to deliver long term cross browser high quality editing functionality.
The size comes mainly from the UI library (ExtJS) we use and synchronous loading. Both changed (with a huge refactoring for 0.10) or will change in near future. ExtJS replacement is currently under dev and we will reduce the size significantly to estimated 300k or less incl ui. https://github.com/alohaeditor/Aloha-Editor/tree/dev-jqueryui or http://www.slideshare.net/draftkraft/aloha-editor-jquery-conf#114 (slide 114++) or http://aloha-editor.org/wiki/Migration_to_jQuery_UI or http://www.slideshare.net/romaincarlier/aedc-2011-discussion-about-ui-changes
Further the Aloha Editor core will be able to run standalone (even without UI). We hope to reach less than 120k for the standalone. We can implement your own simple or more extended UI based on your needs.
Thanks for your feedback! Hope this information helps. We appreciate your feedback and or help. Just get in touch.
All best
haymo (AE project lead)
Qoute from Sun:
"Aloha requires ECMAScript 5 which only runs in the latest browsers. IE 8 and older browsers can't use the editor."
That's a good point. But I think the most user group to benefit from this are editors, which means they're just a few percents of end-user in most cases. So, it won't be that hard to make a comparison image/chart and show them the benefit to upgrade to latest browser (which actually, not the latest if the implementation is done in next year or so).
And I just test IE9, it's now good enough and become my day-to-day browser which was never been since 1998. It's easy to convince IE6/7/8 editors to get IE9 or other browser updated this day.
It may not ready to become core module but ready to be adopted by editors, users anyway.
Regards,
Dave
I spoke to Haymo Meran, project lead of Aloha Editor, at Drupal Gov Days last April. The Aloha community is looking for collaboration with the Drupal community to get a good integration between the two systems. If someone needs contact details, just let me know.
Erik Stielstra (Sutharsan)
I'd love to see some more integration for it too - having it in a field-formatter would be a good start. For d7, you could of course use the entity API modules' entity_save().
I guess we could also provide a "full-html" input format with the editor enabled.
However, on the long road even better would be supporting it via the "contenteditable" attribute + persisting the data via web-services... :)
At first sight I wasn't impressed, but after reading through the slides I'm getting why everyone likes this. Didn't new there would be a *real* editor. I'm looking forward to the next version(s).
HTML5 is really popular among all search engines. The core reason to this is it lessen their work and get them a deeper analysis
Make A Mobile Website