I've been thinking of rewriting the whole cleanup process so it's more efficient. But cleanup of long HTML chunks will always be slow in javascript since it's a script language. But I guess a rewrite would make it a lot faster. A server side cleanup is alot better and safer too since then it would be impossible to "inject" elements that isn't valid. We have been thinking of adding a backend API for PHP and .NET. A PHP class and a .NET webcontrol but we haven't got around to do it just yet. Such backend logic could be equipped with a serverside cleanup routine compatible with the valid_elements format in TinyMCE and would be a lot more efficient since we could then SAX parse stuff etc.

Yes, TinyMCE works as good on Firefox on Mac OS X as it does on Windows at least a.f.a.i.k since I don't normaly use the Mac unless I test TinyMCE or other projects on it. But the main testing and development is done on Firefox on a PC with Windows XP and testing is always done in MSIE on PC aswell before we ship any release out.

Yes, the numbers increase if the business focus is on advertising agencies or some web companies that focus on design. But most of our customer base out side TinyMCE or the commercial plugins on this site tend to use MSIE. And there it's about 100% of our customers. But it's hard to tell how many of the TinyMCE users or the user base on systems that uses TinyMCE realy is.

If anyone have a big site that uses TinyMCE like a blog or something please send us some stats.

I would love to see a php API. 

Sorry, I meant a php API for the entire tinyMCE system... not just for cleanup.    We do our coding using PHP, so it's kind of annoying to output javascript all over the place.  Would be great to keep it in PHP and have some API do everything for us.

ie:

echo value_bold("true");
echo value_italics("false");

And then bingo... it would spit out the required javascript for making this happen...

I know we could do it.. but I'd rather have the coding done by the good folks from moxiecode, since then they would be responsible for maintaining it, updating it with new functions as they arrive, etc...

No, since this is a major change and will most likely not be stable in the first version I will not be able to include it in the 2.0 version. I could make some effort for it in 2.0.1. Anyway, I think this whole problem can be avoided by using the theme_advanced_styles option. If I where to make a more complex CSS handler I would need to rewrite lots of code since this parsing is somewhat complex. I should also move this into a own plugin or similar since the code will be quite large figuring out all possible combinations and so forth.

Use this for now, or make a timmed CSS for while editing and use your more complex CSS while presenting the page this is how we do it our selfs since complex CSS:es with floats and all kinds of custom things can break the editing experience.

http://tinymce.moxiecode.com/tinymce/do … tyles.html

Cause there is an unlimited amount of features that can be added, so no final would ever come out.

Final stable releases are needed for all the CMS systems out there that use TinyMCE, they need the stable versions for integration.

The patch is not in fact very big and does not introduce any new features, it merely corrects a couple of problems - it brings the style sheet processing of Firefox closer to that of IE and it eliminates duplicate class names from the selection list (both bugs IMHO).  The other things that were mentioned are not addressed by the patch (either they not been implemented or cannot be implemented).  If the patch did anything more than I have described here I would certainly not be pushing for it to be included in 2.0 final.

Moving the CSS processing into a plugin is a good idea as it would make it easier for people to replace the code with something as simple or complex as they would like.  Ultimately I want to be able to control which style classes are presented depending on the selected element - no doubt only some people will want this so pushing it off into a plugin makes sense.

The CSS I am dealing with is not in fact overly complex.  I can see that using a trimmed version of a style sheet while editing might solve some problems, but not I think the ones addressed by the patch.

This does not address the issues as elegantly as the patch.

Keep up the good work!

Scott

One issue that continues to plague TinyMCE is the lack of a <!--pagebreak--> function.  Frankly, it is driving a great many people nuts and into moving to fckeditor or others that support this function by default. 

There are posts even here requesting help (where people are trying to create this function on their own) yet those posts are still open.  On top of that, solutions like Mambo have tried (hap-hazardly) to add the function in, but it is using an image type feature to pull this off and the function only works in one place designed specifically to look for that specific image tag to interpret it and convert it that way.

The bottom line is that 2.x should include a standard pagebreak button that would inject the code and be an allowable definition (if added as such).  To think that you folks could do all of these other functions but not create a standard pagebreak is just nutty.

Just my 2 cents

First of all I must say that TinyMCE is not a mambo plugin or any other CMS specific plugin so we only develop platform neutral logic not Mambo specific or Xaraya specific functions.

I will have to aggree with jojodee that this will have to be treated as a CMS specific implementation. If I where to add this as a base functionality for TinyMCE it would only be useful for systems using this approach to produce pages. In my oppinion is not a efficient and ideal solution anyway, it seems to be a quick and dirty hack. We did a simmilar thing for postnuke once.

And if we where to add this to the core it would have to be smart in two ways. It would need to be placed after paragraphs and out side tables so they don't break and they would need to be visible so users can remove them simmilar to the anchor elements. And that kind of functionality isn't done right within a coffe break.

I think the best way of doing this is to produce some kind of code snipplet plugin so it would be possible to inject any custom content within visible containers since diffrent CMS systems implement these page breaks or simmilar snipplets in diffrent ways. But this will have to wait for the 2.0.1 release, we must first get the 2.0 stable and out before adding more functionality stability is far more important than cool features.

To hstraf and Spocke, I couldn't agree more. A pagebreak function is cool, and in many cases a great function - if it works flawlessly. However as Spocke mentions, it isn't something I feel belongs in a WYSIWYG editor, since it needs to be treated serverside afterwards - which again makes it a CMS specific function. I remember I had a customer aswell who wanted this function, and referred to Mambo (note, i havnt checked mambo lately), and Mambo was superior for this functionality while my system (TinyMCE, FCKeditor, Xinha and htmlArea) was crappy since they lacked it. A fast test hower inserting the pagebreak within a table broke the design big time in Mambo, which in turn brings me to Spockes point that such a function needs some amazing logic which isn't buildt in a jiffy.

Sure, I would love such a functionality - but is it reasonable to expect it to appear in TinyMCE, or should we let the developers focus on the core itself. If we look at the typical user of a CMS (People like me who are looking for functions like pagebreak are, in my belief, all persons using the WYSIWYG in our CMS), so the typical user is a person who doesnt know alot about HTML, probably nothing (If he knew HTML, he would probably use raw HTML, BBcode or MarkDown for optimal control in theese XHTML days). So what does a typical webpage in a WYSIWYG rendered page look like? It could be one table surrounding the entire page which is, say 5 pages long, containing 4 pagebreaks.

This would mean that we would make the Moxiecode staff spend a heck of a lot of time for this "seemedly" easy plugin to accually rewrite the entire code of the page to work with the pagebreaks (Or this is probably where our own serverside system gets to work), we can't just do what Mambo did (again, maby they solved this lately, I havnt checked), assume that the person using the WYSIWYG is not using the plugin wrong - after all it's WYSIWYG so people tend to do alot of wrong things (Did I mention paste from word and other websites, even if told otherwise)...

Lately I have spent more and more time using TinyMCE, but I would like to share my 2 cents here to be sure that the development is going in the right direction, and not focusing on messy plugins which will hault the development unneccesary. After all the developers are doing a great job on this free tool, and it doesnt hurt if we support them once in a while instead of always demanding new functionality all the time. Finally, as hstraf mentioned, if you really like this plugin to surface the people at Moxiecode will more than happy (ugh... As George Carlin mentions this is a pretty meaningless condition, hehe) spend time developing it for you if you are willing to pay for it.

Looking forward for the next release of TinyMCE, I will need to upgrade alot of users again... Keep up the good work

Mvh,
Kim Steinhaug
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.steinhaug.no - www.easywebshop.no - www.easycms.no