Page MenuHomePhabricator

Inconsistent display of CSS pages - rendering CSS source as wikitext
Closed, ResolvedPublic

Description

Author: kelvSYC

Description:
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.


Version: 1.10.x
Severity: minor

Details

Reference
bz8624

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:35 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz8624.
bzimport added a subscriber: Unknown Object (MLST).

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...)