Currently wysiwyg_get_css() assumes the CSS is local, but that's not necessarily the case in D7, where drupal_add_css() can take external CSS. The attached patch makes external CSS work, loading in the editor iframe when "Use theme CSS" is selected. Tested in TinyMCE.

It would be nice to have some way to do external CSS in D6 WYSIWYG, where drupal_add_css() isn't an option, but I'm not sure how that would work.

Comments

One way to get external CSS working in D6 is creating a wysiwyg_add_external_css() function to clone the functionality in D7 drupal_add_css(). Then anything that adds external CSS via drupal_set_html_head() in D6 could use wysiwyg_add_external_css() to make the CSS available in WYSIWYG. That doesn't seem like a great solution, but I can't think of anything better.

I can do tests. Should I bother continuing after I find one editor that doesn't support external CSS? Is the general approach for WYSIWYG to do conditional support for functionality in specific editors or to only support functionality that works everywhere?

Please continue even if some editors fail the test. It's better to exactly which ones that don't support a feature rather than "at least one".
We try to support as many features as possible for each editor, but so far we've been limited by the profile configuration GUI which can't be customized for each editor (not all widgets available have an effect in all editors).
But now my point is more that this feature is implemented in wysiwyg.module, rather than in the editor-specific .inc files, so each .inc file must be able to "opt-in" on external stylesheet support. Though, if every editor appears to support, or at least won't take harm from, this featue that might not be needed now.

Whizzywig needs the global JavaScript variable cssFile set to load a stylesheet. We don't currently set it, but can you try doing that by modifying the .js implementation file?

WYMeditor only loads one file (the first one), so try specifying it using Editor CSS: Define CSS and CSS path: path-to-external-styleheet on admin/settings/wysiwyg/profile/#/edit or by overriding the value completely via hook_wysiwyg_editor_settings_alter().

If you get openWYSIWYG running in another browser, the current implementation overrides the stylesheets in the clientside implementation, so you might have to modify that too to test it.

YUI Editor needs at least one toolbar button enabled to not throw that error.

MarkItUp, WYMeditor and jWYSIWYG don't support stylesheets at all, so no surprise there. :/

Whizzywig: I'm not sure which file you mean by "the .js implementation." I can hard-code external CSS in whizzywig.js and that works, but doesn't seem like a very relevant test. I don't see where CSS is being sent to editors in any of the JS files in the module.
WYMeditor: Does not work. External CSS has no impact.
openWYSIWYG: Does not work. External CSS has no impact.
YUI editor: Works.

So everything either works or has no impact. Nothing breaks with external CSS. Is that enough to call this RTBC, or do you want to try to fix all of the editors that don't handle external CSS?

I meant wysiwyg/editors/js/whizzywig-60.js (and the earlier versions too, but testing one is enough).
You'll notice that we set the global window.buttonPath variable before attaching the editor (so it can be different for different fields), the same thing would have to be done with window.cssFile.

Things not breaking because of this change is very positive. Fixing stylesheet handling (where the editor supports it but Wysiwyg doesn't) is a different issue, the importand part here is that editors won't crash or behave strange when they see [absolute] URLs from another domain.

As whizzywig does not need to accept external CSS for this patch to be useful, and this has been waiting for 9 months on a patch that has no apparent problems, can we please handle that in a separate issue?