I would like to be able to dynamically switch the content stylesheet.  This would be used to allow a user to select from a set of available stylesheets to apply to the content.  Some might define the same class names to provide alternative renderings of the same content, others might provide a completely different set of styles such that the user would need to re-style the content.  Providing for the selection of the stylesheet within the editor would only be useful if the setting could be retrieved for inclusion in a hidden field - but as long as the stylesheet can be specified via a script then this would be fine.

With regards to the comment quoted above, what is gained from an XML configuration file for styles?  Yes, you might be able to encode information concerning how to apply the style elements, but in terms of flexibility it is much more interesting to me to be able to offer a bunch of different stylesheets without having to go and recode every one as an xml file as well.  This is one of the things that turns me off FCKeditor.

How about using annotations in a regular css file to provide any additional information?  If they are not present then the editor could make the best guess as to what to do, but if so the editor can use them to deliver a better result.

I'll post the basic dynamic switching of stylesheets concept as a feature request on sf.net.

Thanks,

Scott

Last edited by seade (2005-08-05 06:32:31)

Support for Opera browser...

plugin for body tag.

Better explanation on how to write your own Plugins.
I am not quit experienced in programming (just have done some easy php stuff), but an example on how to insert hello world tekst, should give an easier start to write an own plugin, maybe then i get the _template example working.....(now i dont even get a button in my menu)

Furthermore: this is a real great script.......best i have seen.

Just to throw my 2 cents in.

I really would like to echo the sentiments of the previous posters vis a vis style selection. It really is hit or miss (most often miss). Yes, if I author content directly in the editor, then it is quite stable. The area where it really lets down is when you cut and paste from another source. Sometimes selecting a style when the cursor is at the beginning of the sentance will apply the style to the whole paragraph. Sometimes, nothing will happen. Also, highlighting a paragraph and selecting a style will sometimes work, but most often not.

Someone made a great comment that users using Tiny are worried about inputting data, not selecting styles. With that in mind, it would be great if at the page level, a user could select that they would use a particular style. Then each and every <p> or <td> element would default to that style, unless a user wanted to change it. At least for me, I use really only 2 or 3 styles within the content area (the rest being within top nav, footers, and sidebars which users don't need to control directly).

One thing that would be a huge help to Tiny is the ability to define at a global level the doctype declaration that your site supports, then present validation/cleanup functionality based on that selection. Certainly, some users have figured out a way of including xhmtl field validation, but it would probably be better to bring this into the core app rather than a big 250 line declaration in your html.

Also, as users can quite often delete stuff that they shouldn't, it would be great if you could implement a tag that told Tiny where to start and stop. Everything in between Tiny would stream to the applet, everything outside a user wouldn't see (except for preview).

I also agree with a previous poster who mentioned the HTML view. It would be a great idea to allow users to toggle their view inline. The current html pop up window is far too small to be useful (ie you have to manually resize before you can really view the code).

Really big fan of TinyMCE. Hope these comments weren't construed as complaints! Keep up the great work.

Geoffrey

I also use a commercial editor that uses non-standard css properties to do this sort of thing (these are ignored by user agents) and it works really well.  An example is that they use a "visible" property to hide an included style from the editor - e.g. MsoNormal can be hidden thus:

p.MsoNormal {
    visible: false;
}

I would prefer to see a namespace qualifier, e.g:

p.MsoNormal {
    tinymce-visible: false;
}

There is no reason why you couldn't do things like:

.myBorderStyle {
    tinymce-applies-to: p,li,div;
    tinymce-keep-word-class: true;
    border: 1pt solid black;
}

"tinymce-applies-to" could be used to adjust the list of styles presented to users when editing content.
"tinymce-keep-word-class" could be used to retain the class attribute when content is pasted in from Word.

No doubt there would be other interesting annotations that could be encoded via css properties.

I reiterate my opinion that annotation of style files is a better alternative to xml files as it allows a single file to deal with these issues rather than requiring an xml file to be maintained in parallel to the css file.

Scott

Hmm, TinyMCE is now days released as with RC:s until I think it's stable enough to call it stable. TinyMCE will never be 100% stable nor will any other edtior be since some bugs are browser issues and not bugs within TinyMCE. I have already made numerous workarounds for browser bugs and issues.

Setting up a test suite for a browser based editor is very hard since it can not be automated. If it where a server application or API I could simply setup a unit test for it but since may bugs are only produced is a user clicks in specific ways etc.

But if there are users out there that would like to help me to beta test TinyMCE please let me know. We could then setup some form of beta test program, it's getting harder and harder for me to test all sorts of configuration combinations a user can have.

I would definitely cast my vote against any non-standard CSS or HTML attributes.

There are many of us who develop our web sites to the exacting W3C standards, and include the validation buttons on our sites to demonstrate our compliance with W3C standards, including XHTML, CSS, and even RSS standards.

Any non-standard CSS entries would break compliance, and would turn off a good many developers here.

On other matters mentioned in this thread:

- Putting language packs in one place would be excellent for maintenance, but would affect plug-in development and deployment, so it needs to be thought-out.  The concept of one resource pool for all modules is used by other major frameworks (like DotNetNuke), so it is certainly feasible.

- There was mention a while back about a .NET version of the compressed loading (GZIP) routines - is that still on the agenda?  That would help solve download times for us .NET junkies big-time!  Without such compression, load-time is becoming a big issue.  As the features get better and better, load time is going up and up.

- I'd love to hear from TinyMCE on where things stand as far as development of standard DHTML popup functionality.  First of all if it is on the agenda at all, and if so, what is the plan?  Getting rid of popup windows altogether will be a great big step -- something I'd love to see.

Lastly, I'd echo others who mentioned that all comments are intended as constructive, and not critical at all.  In my book, TinyMCE really is the best overall solution for content editing, and I'm constantly amazed at the talent of the developers.

Let's just say we agree to disagree.  There are some people who take the approach you're specifying, and some who are very much against doing so.

As the CSS parser discards the illegal properties they never appear in the DOM and hence the outlined solution wil not work anyway.

So there is actually nothing to disagree about.

Scott

BETTER DOCUMENTATION ON SETTING UP tinyMCE! .... Documentation needs improvement.  Dont believe it?... just read the forums and see all the questions regarding configuration. And what's with the ... "go read the docs ... figure it out yourself" reply's?  What the hell is the BB for then?

Don't get me wrong tinyMCE is a great editor but trying to get the thing to do what you want is trial and error because of the lacking documentation
of how to acutally do things with it. 

"That's my story and I'm stickin it to ya!"

i would be happy have a plugin for inserting templates.
have a look to fckeditor to understand my wish.

I agree -- in fact, I had mentioned it here:

http://tinymce.moxiecode.com/punbb/view … 5556#p5556

Yes, our main focus is "normal" users not hackes. They tend to use a plain text area box anyway and hack in their own tags.

But it's hard for us to make the manuals "noob" friendly since we are developers our self. The best would be if someone less skilled wrote a how to.

But we have been thinking of adding more examples to the TinyMCE site and add a box below each example displaying the code the user needs to copy/paste in to their site to get the same results. But there is so much on our todo list, but it's in there some where.