[daisy] [JIRA] Commented: (DSY-475) Consider basing the HTML editor on another open source project (instead of HTMLArea)

[Alan Mortensen (JIRA)]

    [ http://issues.cocoondev.org//browse/DSY-475?page=comments#action_13614 ] 

Alan Mortensen commented on DSY-475:
------------------------------------

I'd be a little wary of any OS solution that is backed by one company (TinyMCE), that's what happened to htmlarea.  The ones I've heard of are Kupu and FCKedit.  Regardless, this would fix my problem with allowing onclick actions to get through which is something I've tested with a number of modern editors, all of which worked.  Plus my users would certainly enjoy a more functional spell checker.  Also Safari support would be appreciated since a fair percentage of my users are mac people.

> Consider basing the HTML editor on another open source project (instead of HTMLArea)
> ------------------------------------------------------------------------------------
>
>          Key: DSY-475
>          URL: http://issues.cocoondev.org//browse/DSY-475
>      Project: Daisy
>         Type: Improvement
>   Components: Frontend - doc editing - HTML
>     Reporter: Bruno Dumon
>     Priority: Minor

>
> Background: browsers such as Firefox and IE provide HTML-editing capabilities. Based on this, there are some projects developing fully functional editors around this, that is, doing the common stuff such as initializing the editor, adding a toolbar, and implementing editing functions such as table manipulations that are not provided by the browsers themselves.
> Currently Daisy uses a customized version of HTMLArea. The customization is through plugins or by replacing functions, the original codebase is still the same. Just about any action (toolbar button, dialog) has been replaced with a custom version, either because we wanted it to behave differently, or because it was broken in some way.
> Meanwhile (during the past 3+ years), HTMLArea development stopped, and the alternatives such as FCKeditor, Xinha, ... were unconvincing (i.e. not doing anything better - or even worse - then we had already). The base editors inside the browsers didn't really improve. Things start to change though, and people are finding more and more advanced tricks to work around the limitations of the built-in editors. TinyMCE seems quite impressive for example.
> Things we could gain from moving to a newer editor base
> ==========================================
>  - support for more browsers
>  - profit from more enhanced basics, e.g. TinyMCE has a custom undo system, advanced ways of inserting inline elements, ...
>  - being based on a project which is alive, thus gaining from the improvements made by other people and being able to fix things at the source
> Some of the customizations Daisy does
> =============================
> (a detailed study of the current sources should be done to know all current behaviour)
> - keyboard:
>     - shortcuts: e.g. ctrl+1/2/3 for heading levels
>     - IE: avoid tab key moving to other controls (instead support moving through table cells using tab, and in/out denting lists)
> - on editor load:
>     - insert link to CSS
>     - translate ?daisy:? links on images to public URLs
>     - special handling for href's to avoid IE changing them
>     - loading of include previews
>     - inserting br's in empty table cells (needed for FF)
>     - apply column widths for tables
> - inside include previews, editing should be disallowed
> - custom actions/plugins:
>     - lots of custom dialogs
>     - switch to source does server roundtrip to use our htmlcleaner (could be made into ajax call)
>     - (lots more)
> Other notes
> =========
> - fallback to a textarea on browser that don't support HTML editing is a good thing

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira