Help Text for CKEditor's Font Style CSS classes needs improvement.

Nice issue description.
Looks good to me. Any objections, Sun?

+++ b/editors/ckeditor.inc
@@ -133,9 +133,10 @@ function wysiwyg_ckeditor_themes($editor, $profile) {
+    $form['css']['css_classes']['#description'] = t('Optionally define CSS classes for the "Font style" dropdown list.<br />Enter one class on each line in the format: !format. Example: !example<br />Multiple classes may be added to an individual element. Example: !example2<br />If left blank, CSS classes are automatically imported from loaded stylesheet(s).', array(

I think there are two issues here:

1) The entire text talks about classes, but the actual definition is about block formats/styles, not classes. This especially makes this part very confusing: "Enter one class on each line in the format:" -- it sorta implies that there can only be one class. But it actually means "one format on each line." (perhaps "selector" would be a more appropriate term; but then again, IIRC the editor only supports tagname + class[es] combinations)

2) I'm not sure whether we need an entire separate sentence to clarify on multiple classes. What if the example snippet just simply showed that possibility baked-in? E.g., Title=h1.first-class.second-class

What do you think?

Good points, that could get confusing to someone not already familiar with this feature.

CKEditor actually supports a lot more complex style sets, take a look at http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Styles

You can make the Font Styles dropdown apply pretty much any attribute or style to the current selected element.

I'm pretty sure that we won't be able to support arbitrary attributes within that textarea -- or at least, that would be massively complex parser code and most probably require a syntax that no one understands ;)

I wonder whether this would cut it?

Enter one format on each line: Title=h1.first-class.second-class

That would be on the assumption that the users who are configuring this can make sufficient sense of the example snippet and understand that the actual syntax is my label=element[classnames] (classnames are optional) — so instead of trying to explain the syntax in words, the actual example helps users more.

Since this a custom string syntax that is being parsed by the module, I don't think that a link to CKEditor's documentation would be helpful (I'd think it would be misleading and confusing, actually).

@carwin, the old description is still valid for TinyMCE.

I just did a grep -lr css_classes . inside the wysiwyg folder to see which files uses the 'css_classes' property.
The result was pretty disappointing.

./wysiwyg.admin.inc
./editors/ckeditor.inc
./editors/tinymce.inc

Problem: The css_classes feature is only supported by two editors, (3 if #671528: Support custom css styles gets some more attention), but it's shown for all editors.

Suggestion: Remove any mention of this feature from wysiwyg.admin.inc and move the code from wysiwyg.admin.inc to tinymce.inc, adjust ckeditor.inc as needed.

Result: Users aren't tricked into thinking we support this feature for the other editors, less confusing UI, easier to customize the implementation for each editor.

Implementation: Removed all code related to css_classes from wysiwyg.admin.inc. Moved the complete css_classes element definition to ckeditor.inc and tinymce.inc. Used a simplified validation regexp in tinymce.inc since it only supports one classname (haven't checked their code, but the examples only use one class). Made sure the css_classes setting is initialized if it doesn't exist. No need to remove it from existing profiles since it won't hurt and it will automatically be skipped if not needed when profiles are saved.

Additional: I found something odd in the validation regexp for CKEditor. It looks like this: '@^.+= *[a-zA-Z0-9]+(\.[a-zA-Z0-9_ -]+)*$@', which would not allow _ or - in the first classname, so I changed that to: '@^.+= *[a-zA-Z0-9_-]+(\.[a-zA-Z0-9_ -]+)*$@'. Validation works better now.

Changed 'altered' to 'added' in the element validation function comments, since the css_classes element no longer exists by default.

This patch no longer applies.