It's hard to know what people want in future releases of TinyMCE. So I made a poll out of some of the key features I would like to add.
If I were to place them in order, this is my vote:
1. DHTML windows, possibility to use layers instead of popups
2. Better cleanup options (cleanup chaining) - more control over cleanup
3. Performance, it's to slow make it run faster.
4. Reduce size, it's too big make it smaller.
5. Safari support, focus on making it work on Tiger/Safari.
6. Better documentation (make it up to date and add lots of info)
7. Separate toolbar, floating toolbar or within a external div.
8. Better CSS style support (having a style inspector, XML config for styles)
9. Spellchecker in PHP and possible .NET
I tend to focus on things that directly impact non-technical end users. For the spell checking, I think IE Spell is an awesome spell-cehcker, and it's best to keep that as a separate plug-in. (Plus focusing efforts on non-platform-specific things.)
All those things listed sound good. As far as the spellchecker goes, don't use one that uses Aspell, as this may be useless to a lot of users. Have a look at phpspell instead. I'm hoping to convert this for mosCE users soon, so maybe I can make it available for general TinyMCE use.
A forms plugin would also be great, as well as moving all the font stuff to a plugin.
A mosCE user once requested Searc&Replace features for the HTML editor, and syntax/tag higlighting as well. Any of this possible?
Other than that, nothing I can think of right now. TinyMCE is really good, and the stuff I've seen in CVS for 1.45 make it look even better! 
Thanks
Ryan.
Simple things like clicking on a image and then clicking on centering have stopped me using this great fast small application.
Small bug fixes first please!
My highest priorities would be:
1. Safari support
2. Unicode support (maybe I just don't know how to do this)
3. Better documentation
The most important thing first:
Make it smaller and make it faster !!
Use the PHP script if you can.
And try to show us an editor that loads less than 45-50kb and is as flexible and well written as TinyMCE.
IMHO, the future releases should concentrate on the followings:
1. Performance and loading time (as of the actiual version it takes too much to load) (maybe to split the IE and Mozilla code in 2 files would reduce what's to load to 50%)
2. Better and smarter CSS support: allow diff type of selectors based on thier context only(this would be the killer feature 
)
3. Document the sources and explain the functions with JSDoc: http://jsdoc.sourceforge.net/ (this won't be a problem for the size, since this should go only in tinyMCE_src.js, not in the 'obfuscated' file.
4. Spell checker for Mozilla: on the sourceforge there was proposed a solution that works with Mozila/FF on in the browser only. IMHO even if it's not perfect it's still better than nothing, since for IE there's one allready. Solutions that require serverside work shouldn't be considered cause everyone is using a diff. platform.
Ahmed.
Is there any other editor out there that loads faster than TinyMCE? And has the same functionality/flexibility.
The included PHP file compresses the scripts down to around 45-50kb, thats quite reasonable in my opinion.
(If scripts seem to load slow on our server, its probably cause of our connection, or yours).
Is there any other editor out there that loads faster than TinyMCE? And has the same functionality/flexibility.
This is not the point. Just because the others are bad, it doesn't mean you can't improve user experience.
Our users open and close very offen the WYSIWYG and their main concern was that only the WYSIWYG was slow from the entire application.
The included PHP file compresses the scripts down to around 45-50kb, thats quite reasonable in my opinion.
Yes I know that compression is one step to do, and there are tones of tools to do this (see thread on these forums), but TinyMCE does not consist only of tinyMCE.js .
It might be a bad idea, but maybe separating in tinyMCE_Moz.js and tinyMCE_IE.js would reduce a lot. If you look in the code in a lot of places there's : 'tinyMCE.isMSIE'. If the two would be splited than there would be need only for one of that sentence, not to mention that only one of those 'half files' would be used
(If scripts seem to load slow on our server, its probably cause of our connection, or yours).
This is on our servers too, and it has nothing to do with the connection. The total loading time(from a user perspective) it's the time till the entire WYSIGYG is rendered in a 'usable form'.
So maybe the preceived perfomance it's not only the size and the connection, but also what's executed until the WYSIWYG is ready .
Thanks in advance,
Ahmed.
P.S. We always used the advanced theme (and the most of the users use it also), so... .
Well, TinyMCE code is already very optimized (that's why its faster than most other similar editors). The biggest limitation is probably what computer you run TinyMCE on, as well as how well your browser renders to the screen etc.
The compress file doesn't only compress the tinymce.js file, it compresses all plugins and makes into a single request (instead of seperate requests for each plugin). This IS the fastest way to render the editor. Seperating IE and Moz wouldn't give much of an performance boost.
Any chance of writing a similar compressor for ASP? If not, can you explain how the PHP compressor works, so I can write one myself? Thanks!
Its going under some modification soon, to fix the problem with multiple inits etc.
I think Spocke can better explain how it works.
The PHP compressor takes out the theme, plugins, language options makes a list of .js files it needs to load. Adds these into one long data chunk and gzip compresses this one and sends it to the client, since all modern browsers support gzip requests this is a ideal way of sending large chunks of data to the client. This makes 50 request to become 2 and From 252kb obfuscerat till 44kb. So it loads alot faster, can't be much faster than that.
But as Afraithe said, the PHP compressor has issues with multiple init calls and it should have disk cache for the gzip:ed streams to boost server performance. This will be addressed in 1.47 of TinyMCE. But you could still port this to asp or aspx if you have the motivation.
OK, thanks for the detail.
Ability to add forms with Tiny.
well i would like that when you press "ENTER" it makes a BR rather than a P. So that there's no double spacing.
but i know what the problem is with the number listing, because with br's you can't make a number listing properly... like the numbers wont follow.
So i suggest you make use of the div tags rather than the p or the br, that way, when you press ENTER there no double spacing.
1. DHTML windows, possibility to use layers instead of popups
This has got to be #1 for most people. Who doesn't have a popup blocker these days? A popup shouldn't be needed for things like smilies...
Firstly - TinyMCE is an excellent product.
However, I really think you must get INLINE-STYLES working 100%. This is critical. All other DHTML rich text editors use inline styles for formatting. This is essential as it is the only way to really guarantee format durability. FONT tags are 20th century stuff that should really never be used - any outer CSS overrides HTML format tags -
I understand your position on using styles and classes, but for this feature to be really usable, you need to be able to show the end-user graphically what the style is in the style drop down. The font family and font size drop downs must use inline styles.. or they are effectively useless.
Except for this, great product - getting the inline styles right and this will be 100%.
Just as a follow up to previous post - another main reason why a style list cannot replace the font family and font size lists - you cannot have a style for every combination of font size and font family, alignment etc- this is clearly not practical. It is important that fonts, alignments, font pitch are all replaced with inline styles.
I concur with MoonPool.
7. Separate toolbar, floating toolbar or within a external div.
i've make this ==> http://tinymce.moxiecode.com/punbb/view … 3553#p3553
is it ok ?
One thing that came to my mind was the better HTML source editing. I think some of you TinyMCE developers already said its in the todo list?
I mean that it wouldn't open a popup for the source but it would use the existing textarea to display the code and disable (grey out) all the other buttons but the HTML code-button. So it would be a toggle button.
OK, my first post here, but I have just been through Xinha and FCKeditor and decided TinyMCE is the place to be. And just for starters a small rant.
I would like to make a big vote for context sensitive style classes.
you cannot have a style for every combination of font size and font family, alignment etc-
I say hooray. What kind of document has that, unless you are designing Victorian handbills?
It seems everyone needs to be a typographer these days. I see people who are good at their jobs, get bogged down with MS Word choosing a typeface, should this or that be in italics etc. It is nothing to do with the information they are trying to convey. Similarly TinyMCE is not the place to start making design decisions. I think it should be a place to record text and apply style, not invent new styles.
The look and feel of the site needs to be embodied into the style sheet. People using TinyMCE are providing data to a site, and should be constrained to the look and feel of the site, not encouraged to break it. If they apply a named style it can be easily redesigned without affecting the content. I know it sounds harsh, but I firmly believe that design and content should not be muddled up.
Application of styles right now seems a bit hit and miss, in that you can apply a named style which wont work. So context sensitive please!
And I will build the style editor, unless anyone knows where I can find one?
End of rant.
Steve
The look and feel of the site needs to be embodied into the style sheet. People using TinyMCE are providing data to a site, and should be constrained to the look and feel of the site, not encouraged to break it. If they apply a named style it can be easily redesigned without affecting the content. I know it sounds harsh, but I firmly believe that design and content should not be muddled up.
I definitely second that.
And I will build the style editor, unless anyone knows where I can find one?
Not sure what you mean here: are you perhaps looking for something like this?
Alessandro
You are not logged in. Please login or register.
