TYPO3 Core

It should be possible to edit bugs, or I should get more sleep. The report is correct, but I've incorrectly identified the purposes of the stylesheets. They occur in this order:

1. The custom RTE stylesheet
2. The RTE's content stylesheet
3. The RTE's general stylesheet

And I suggest they occur instead in this order:

1. The RTE's content stylesheet
2. The RTE's general stylesheet
3. The custom RTE stylesheet

Sorry for confusion ;-)

Please apply and test the attached patch on SVN TYPO3_4-2 revision 3471.

Could you provide a test case for this issue?

I don't think the proposed solution will make any difference. I am not even sure there is a problem. The iframe is constructed with linked stylesheets RTE content stylesheet followed by custom RTE stylesheet.

I don't think the proposed solution will make any difference. I am not even sure there is a
problem. The iframe is constructed with linked stylesheets RTE content stylesheet followed
by custom RTE stylesheet.

I don't understand what you mean. As I indicated in the bug report, in TYPO3 4.1.5, the resulting iFrame includes the custom content stylesheet FIRST. If the new TYPO3 skin is used, the RTE content stylesheet sets a font-family for the class ".htmlarea-content-body". Here's the code (edited for readability) from the installation where I discovered the problem:

------ Start:

<div class="typo3-mediumDoc">
<form action=" [ snipped ] " method="post" enctype="multipart/form-data" name="editform" onsubmit="return TBE_EDITOR.checkSubmit(1);">
<link rel="alternate stylesheet" type="text/css" href=" [ snipped ] custom-content.css" />
<link rel="alternate stylesheet" type="text/css" href=" [ snipped ] htmlarea-edited-content.css" />
<link rel="stylesheet" type="text/css" href=" [ snipped ] htmlarea.css" />

------ End

Any font-family declaration of equal or lesser specificity on the same class in the custom content stylesheet will be overriden by the regular content stylesheet since it comes last in the cascade [1]. So, for the test-case, simply add something like this to a custom content stylesheet--there will be no change in the RTE's appearance after the BE is reloaded:

.htmlarea-content-body { font-family:palatino,"times new roman",serif; }

As also mentioned in the original bug report, in this specific case it should be possible to override this by using a more specific selector, or by using "!important" in the custom CSS file, but this will not necessarily be true in every case or for every skin.

It's not a huge bug, but there most definitely is a problem in that the load-order of the stylesheets is opposite what you'd do in cases where you had control of the source code.

Notes
----------
[1] http://www.w3.org/TR/REC-CSS2/cascade.html#cascading-order

"Finally, sort by order specified: if two rules have the same weight, origin and specificity, the latter specified wins."

The css order that you see on the page source and that you are describing is used only for pre-loading purposes. It is not the order used in the iframe itself (which you do not see in the page source, right?).

If you add

.htmlarea-content-body { font-family:palatino,"times new roman",serif; }

to your custom-content.css file and clear your browser cache, it will be applied inside the iframe.

I just (re-)tested this in IE7, FF2 and Safari 3 with TYPO3 4.2.

I re-tested this issue again with current trunk. I think there is no issue. The RTE iframe is dynamically created and the stylesheets are also dynamically linked in the following order (see initIframe() in htmlarea.js):

htmlarea-edited-content.css
defaultPageStyle (generated based on Page TSConfig)
custom-content.css

Thus providing the requested order.

Note: Reloading the page may not be sufficient to replace the RTE iframe css. Clearing the browser cache may be necessary.