Are you planning to rewrite tinyMCE in jQuery ?
I know it sounds crazy, but with jQuery, you write less and do more.
Do you think the package would be lighter, given the fact that jQuery is getting more and more common, and weight less than 20kb.
I think we would also get rid of many inconsistancies amoung the different browsers/platforms...

This is interesting. What exactly is the problem with jQuery's namespacing?

~ Brice

Maybe you could use Ext.DomQuery from Jack Slocum? This API really rocks!!!

I am switching to TinyMCE  in my own CMS. I am completely satisfied with size and load time, the feature I really need is working “auto_resize” attribute. I would like to offer you an advice:
To get this feature working you simply need to set vertical size of middle cell to 100%. This will allow editor to work in mozillas / opera (and probably other browsers), but not in IE. To get it working in IE a small hack must be done outside the editor. I am (for example) setting the height of cell, containing the control to appropriate size on client side via javascript. This technique works with FCKEditor, I think it will work with TinyMCE as well. The hack is needed for standards compliant mode only, in quirks mode all will work as expected, though quirks is not a solution in most case. If you wish I can send a working piece of code.
Thank you for a great editor!!

function GetIEClientHeight()
{
    //IE 6+ in 'standards compliant mode'
    if(document.documentElement && document.documentElement.clientHeight) return document.documentElement.clientHeight;
    //IE 4 compatible
    else if(document.body && document.body.clientHeight) return document.body.clientHeight;
    else return null;
}

function FixIE(Height)
{
    var FixedHeight = GetIEClientHeight();
    if(FixedHeight == null) return;

    FixedHeight -= Height;
    if(FixedHeight < 0) FixedHeight = 0;
   
    document.all['MiddleCell'].style.height = FixedHeight - Height + 'px';
}

where 'MiddleCell' is the cell, witch  contains editor (or something other);
variable ‘Height’ is summary size in pixels of elements above and below MiddleCell plus some additional space, its value is difficult to calculate, but it never changes for particular page.

Function FixIE(…) must be called when page is loaded or resized.

working example: http://www.tambov.gov.ru/Default.aspx?Page=138 (xhtml 1.0 + vertical scaling of table with 3 rows)

Hi everybody!

I sometimes change my content unwillingly because TinyMCE still keeps my selected content "reachable" although I'm dealing with a dialogue window of some kind.

Just imagine you would like to set a link. You select the portion of text you would like to be clickable and then click the "insert/edit link" button to get the "Insert/Edit Link" dialogue. When the dialogue finally finishes loading I would directly start typing the URL to my link's  destination ... but TinyMCE will change the selected portion of text to what I now type! Although I can't reach the editor itself (I use the inline popup plugin - but that's not the problem here!) I still can change its content by typing away.

I was already looking for some kind of solution to this before, but now I had an idea:

I'd like the TinyMCEPopup to be modified in future versions to provide this automatic focus on an input field in the newly opened dialogue window. My suggestion is to modify TinyMCEPopup's onLoad function like this:

onLoad : function() {
    var dir, i, inputs, textinput, elms, body = document.body;

    if (tinyMCE.getWindowArg('mce_replacevariables', true))
        body.innerHTML = tinyMCE.applyTemplate(body.innerHTML, tinyMCE.windowArgs);

    dir = tinyMCE.selectedInstance.settings['directionality'];
    if (dir == "rtl" && document.forms && document.forms.length > 0) {
        elms = document.forms[0].elements;
        for (i=0; i<elms.length; i++) {
            if ((elms[i].type == "text" || elms[i].type == "textarea") && elms[i].getAttribute("dir") != "ltr")
                elms[i].dir = dir;
        }
    }

    if (body.style.display == 'none')
        body.style.display = 'block';

/* HERE COMES MY MODIFICATION */
    // Try to set caret into first text input field
    if (document.forms && document.forms.length > 0) {
        var inputs = document.forms[0].getElementsByTagName("input");
        if (inputs.length > 0) {
            for (i=0; i < inputs.length; i++)
                if (inputs[i].type && inputs[i].type.toLowerCase() == "text" && !textinput)
                    textinput = inputs[i];

            if (textinput)
                try { textinput.focus(); } catch (e) { }
            else
                try { inputs[0].focus(); } catch (e) { }
        }
    }
/* END OF MY MODIFICATION */

    // Execute real onload (Opera fix)
    if (tinyMCEPopup.onLoadEval != "")
        eval(tinyMCEPopup.onLoadEval);
}

Since the file "tiny_mce_popup.js" gets updated with every TinyMCE Release I'd have to do this modification manually every other release. This is why I'd like to suggest this change as an "official" one.

What do you think?

Greetings from Germany,

Felix Riesterer.

Hi abood

Are you familiar with the inlinepopups plugin? I wonder...

Greetings from Germany,

Felix Riesterer.

That's GREAT to hear!  I couldn't agree more.  There are so many JS frameworks out there, and everyone thinks the one they chose is the B-E-S-T.

It is very easy to add AJAX to some JS code without the bloat of a 3rd party library.  I use both approaches myself.  For very simple callbacks I use a stripped-down homegrown function, and for more full-featured pages I use the MS ASP.NET AJAX extensions.

Adding some quick AJAX stuff to TinyMCE increases the code size very little, while relying upon a specific add-on library would instantly bloat the code -- and make everyone either conform to your choice of library or else custom-write their own work-arounds.

Spocke and Afraithe, thank you for taking the position you have on this issue!

Last edited by speednet (2007-04-17 17:32:44)

Yes, we pretty much have a new Ajax API that is very small and Tiny compared to other libraries. I guess we will take the best out of that one and re-scope it into the TinyMCE namespace. This approach will basically make TinyMCE smaller but yet more powerful and still library independent.

Some libraries our there are really cute but they tend to do more stuff than TinyMCE needs and they also tend to mess with internal objects.

I hope you don't talk about technical manuals. Since that is the best we can do, the Wiki contains all the info a developer would need to implement the editor in their system. If you have very specific needs and need to dig in deep the documentation is probably not that good but how to configure it, make plugins etc don't get much better than that. If you think you could do better why not contribute to the Wiki this is after all a community open source project so write away.

If you are referring to user manuals for how to use the editor from a end user perspective those are very our dated and should be moved to a wiki or something but this is not our main priority now.

As an open source project, the developers of TinyMCE are free to work on whatever itch they happen to have.  The most important thing they have done in this area is to set up the wiki itself.  This enables everyone to contribute to the documentation effort.  "everyone" is an inclusive term - if you are not happy with the documentation then you can contribute towards making it better.  If you feel strongly about it then you can contribute yourself.

You can of course influence the priorities of the developers - I am pretty sure they will be happy to work on whatever you pay them to work on.

Scott

How about making use of a cross-platform javascript library - this would have the potential to simplify some of the underlying code and could at the same time make it easier to add enhanced functionality in the future.

The hardest thing to do would be to select the js library to adopt.  One of the current leading lights would appear to be Ext JS (http://extjs.com/).

Have you guys discussed this before?

Scott