Last modified: 2008-01-28 19:14:26 UTC
Page rendering with the 1.9.0 release when it comes to CSS pages (User:Foo/myskin.css, MediaWiki:Common.css, etc.) is inconsistent at best. Sometimes they are rendered as if the raw test is contained in a pre-block, while other times the CSS source is rendered as if it was wikitext. In previous versions, it was almost always the case that User CSS pages had the former while the MediaWiki CSS pages had the latter. In 1.9.0 I've had both behaviours show up in User CSS pages just by changing the skin (from monobook, which had the former, to myskin, which has the latter). Some have done hacklike workarounds such as encasing it in /*<pre><nowiki>*//*</nowiki></pre>*/ constructs to force the CSS content to be displayed in a pre-block, but more consistent behaviour would be better.
AFAICT it is not _that_ inconsistent: CSS and JS subpages of a user page are rendered in a pre block. In a preview, they are not rendered at all, only used. The only inconsistence comes during the save: When the subpage is saved, it is rendered as a normal wikitext, without any special treatment. And because this rendered version is stored in the parser cache, it is displayed that way for some time (by purging the page, you are able to force the unformatted version). The reason IMHO lies in Article::editUpdates where the text is _always_ parsed (without regard to Title::isCssJsSubpage) and the parser output stored into the parser cache. (Note that I would personally prefer if the CSS/JS would be parsed always, as it would allow inclusion of formatted documentation in the code...)
this is void now
