Last modified: 2014-11-18 18:07:26 UTC
Until recently, sitewide css/js pages were parsed as normal pages, so that wiki formatting could be used in them. These pages are often quite large, with parts of them being maintained by different people; being able to link to the maintaner's user page and to structure them using sections and a table of content helped a lot in managing them. So please return to parsing them as normal wiki pages. (The syntax highlight is nice, but it can be also achieved by manually putting <source> tags around code.)
I just changed site JS to work like user JS, which seemed more logical at the time, but it could just as easily be done the other way around. There are, however, unexpectedness issues with allowing all wikitext, basically related to the fact that for the purposes of actually parsing the code all wikitext will be totally ignored, so people will undoubtedly get confused at their templates not seeming to work. Also, if people don't bother with initial spaces or <pre>s, the code on the page will come out all munched up by the HTML renderer. Bug 10410 suggested we allow wikilinks, and this bug also suggests that headings are useful. That perhaps suggests a limited subset of wikitext, but that can get messy fast. Another thought is to detect block comments and treat their contents like normal wikitext, and leave the code itself <pre>'d and run through GeSHi or whatever. But we probably don't want to catch inline comments, which should display normally with the code, so then we have to introduce heuristics to catch block comments, which will also get messy. Overall it might be best to go with this bug's suggestion and just make it pure wikitext as it was until recently, relying on sysops to be clever enough to get it to display more or less properly. User code pages should be changed to match, however, I think.
*** Bug 10425 has been marked as a duplicate of this bug. ***
On users' CSS/JS pages, it makes sense to wrap the whole code in <pre> tags, as they can be used by unexperienced users. However, site-wide CSS/JS can be pretty long and is usually modified only by experienced users, so parsing wikitext is really useful in this case.
Maybe a magic word like __USEWIKICODE__ could be used to switch from <pre> to normal display?
Allowing this for user subpages might pose some security risk, as it can be used to hide malicious code in HTML comments or invisivble divs. Then again, most people probably wouldn't check the code either way...
There is another problem with the colorized versin of JS pages: With long JS pages, like Lupin's Popups JS, the high amount of colorizing etc on the page makes Firefox (and perhaps other browsers) to take a longer time to render the page. In one case, my browser hanged on Lupin's page as well. I think there should be a way to at least stop this code colorizing option on such long JS pages.
(In reply to comment #3) > On users' CSS/JS pages, it makes sense to wrap the whole code in <pre> tags, as > they can be used by unexperienced users. However, site-wide CSS/JS can be > pretty long and is usually modified only by experienced users On large wikis . . . I suspect most users with custom CSS/JS more than a couple lines long are more proficient in the language than the maintainers of a fair number of wikis' site CSS/JS. I'll just let it be wikitext, it's not going to be a problem if a few people have HTML-munched code on their user subpages as a result.
Done in r23617 (see also r23618).
*** Bug 10432 has been marked as a duplicate of this bug. ***
Reopening this, needs to be WONTFIXed and reverted. JS and CSS code renders as illegible crap when just passed through the wiki renderer, which is why it was <pre>d up in the first place. The consistent behavior needs to be fixed up and restored. It might additionally be nice to render links within that, though, as previously noted on other bugs.
Reverted in r23657.
While I understand Brion's motives, this still prevents section editing on large CSS pages such as [[:fr:MediaWiki:Common.css]], which is very convenient. Allowing section editing and links would answer most concerns, I reckon.
I still think that using <pre>/<source> by default, and displaying as wikitext if a magic word is found would solve all the concerns brought up here.
*** Bug 16269 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > While I understand Brion's motives, this still prevents section editing on > large CSS pages such as [[:fr:MediaWiki:Common.css]], which is very convenient. > Allowing section editing and links would answer most concerns, I reckon. There is a workaround on English Wiktionary for section headings: http://en.wiktionary.org/wiki/MediaWiki:JavascriptHeadings.js For an example, take a look at http://en.wiktionary.org/wiki/MediaWiki:Common.js
