Last modified: 2008-01-28 19:14:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10624, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8624 - Inconsistent display of CSS pages - rendering CSS source as wikitext
Inconsistent display of CSS pages - rendering CSS source as wikitext
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.10.x
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: css
  Show dependency treegraph
 
Reported: 2007-01-14 03:42 UTC by kelvSYC
Modified: 2008-01-28 19:14 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description kelvSYC 2007-01-14 03:42:08 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.
Comment 1 Mormegil 2007-03-26 21:16:03 UTC
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...)
Comment 2 Carl Fürstenberg 2008-01-28 19:14:26 UTC
this is void now

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links