[TYPO3-v4] TinyMCE vs htmlArea RTE

[Kay Strobach]

Hi,

why don't we change to aloha at all?
This way we would have the same editor in the fe edit extensions as we
have in the backend.

As we have a CMS this would also lead to better html, as the code is
just semantical and not cluttered with formating stuff (except css
classes/ids) - but this is a ideological decision ....

What is the problem with the editor shipped with extjs?
http://dev.sencha.com/deploy/ext-3.4.0/docs/?class=Ext.form.HtmlEditor
(Sencha license)

There a lot of plugins out there to customize the editor:
http://code.google.com/p/ext-ux-htmleditor-plugins/ (MIT License)

There is also ckeditor ;)
http://ckeditor.com/ ( http://ckeditor.com/license )

So please explain, why tinymce is the best - while there already other
editors in the core? (i just wanna make shure, that the core doesn't
grow senseless) ;)

Beside the question of the editor i do fully agree, that there are
plenty of problems in the current editor.
The main problem for me is the inconsistent configuration possbility
between UI and parseFunc.

Thanks in advice

Regards
Kay


Am 28.06.2011 16:50, schrieb Jigal van Hemert:
> Hi,
> 
> On 28-6-2011 14:57, Dmitry Dulepov wrote:
>> Xavier Perseguers wrote:
>>> our Community Manager, Ben, thought it would be worth trying to have a
>>> (hopefully) objective feature comparison coming from the community
>>> itself, may it be from htmlArea "fans" or from TinyMCE "lovers".
> 
> Looking from the point of improving HTMLArea (because of reasons Dmitry
> mentions later on):
> 
>> I tried both and TinyMCE wins for me in *standalone* cases because:
>> - it loads faster
> 
> That's a tough cookie. I'm sure it's on Stans radar, but starting with
> what he had there is only so much you can optimize.
> 
>> - it is more lightweight
> 
> Probably relate to the previous item.
> 
>> - it creates cleaner code
> 
> That is something which can be improved.
> 
>> - it is more predictable (does not create empty paragraphs from nothing
>> and makes sure that enter always makes a paragraph, not suddently a line
>> break)
> 
> That should also be a point where something can be improved.
> 
>> - it is easier to configure (at least for me)
> 
> This is for the most part a lack of understandable documentation. It's
> obvious that we (me included) need more examples in the documentation
> and more explanation how the various settings combined give the desired
> result.
> 
>> And if we can, we should simplify RTE configuration.
> 
> With the desire to stay backwards compatible, the way the RTE API in the
> core works this will be a hard nut to crack.
> 
> The RTE is also an area where lack of manpower begins to show. Stan does
> an amazing job keeping the RTE HTMLArea compatible with the constantly
> changing browser landscape. I'm personally not a Javascript wizard, so
> I'm rather useless in maintaining the RTE.
> 
> As Georg has noticed in his Aloha project, it is very hard to make an
> RTE work with TYPO3.
> 


-- 
http://www.kay-strobach.de - Open Source Rocks

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org