Last modified: 2014-05-05 17:46:23 UTC
Created attachment 3849 [details] look how it's looking As an example, take http://en.wikipedia.org/wiki/MediaWiki:Common.js; there it has been a custom to include a link to the maintainer of that part of the script. I'm asking that wikilinks in comments are rendered. dunno if it's easy or a hell to do.
Note that this has always been true for user CSS/JS (but in both cases it will show up in the pagelinks table even though the links don't show). It's not immediately clear what the ideal presentation of all this would be . . . wikilinks work like normal? Wikilinks in comments only? Should we do like Bugzilla and keep the brackets so as not to change copy-paste behavior?
(About the component: this is not just a GeSHi issue, it should be fixed whether or not GeSHi is enabled. This may require changes to both core and GeSHi.)
(In reply to comment #1) > wikilinks work like normal? Wikilinks in comments only? Exact parsing rules for comments might be tricky... not sure it's worth the trouble. > Should we do like > Bugzilla and keep the brackets so as not to change copy-paste behavior? This is my inclination, yes.
Treating comments differently is a dangerous business - there differences between browsers in parsing comments, and some css hacks rely on these. See for example http://www.sam-i-am.com/work/sandbox/css/mac_ie5_hack.html
(In reply to comment #4) > Treating comments differently is a dangerous business - there differences > between browsers in parsing comments, and some css hacks rely on these. See for > example http://www.sam-i-am.com/work/sandbox/css/mac_ie5_hack.html > That's not the issue, we are talking about when it's displayed inwiki.
Resolved with fix for 10422.
Fix for bug 10422 rolled back per Brion at bug 10422 comment 10, reopening.
Per notes on bug 10422, there's also interest in being able to use the section editing features for longer files.
Hardcoded syntax hilite behavior is not user friendly. I suggest different approach in bug 10621.
Because my proposal in bug 10621 has been rejected, I'd suggest another possibility: How about creating new magic word, eg. <wiki>. Now, the CSS/JS site would be rendered with GeSHi by default, but parts of the page wrapped in <wiki> would behave like regular wikitext. The <wiki> tag may only work on CSS/JS pages to guarantee it won't be used elsewhere. However, I don't think selective restriction of what will be parsed (wikilinks, headers) and what not (formatting, other stuff?) isn't the best approach. We should not limit users from having the CSS/JS page in friendly commented way, regardless the possibility of splitting long stylesheets in subpages which would include longer description of such part of the stylesheet. Taking of the chance to vote apart from user isn't friendly. I understand that GeSHi way of displaying of CSS/JS pages _as_default_ is good idea, no doubts, but on the other hand the final decision should remain on user.
*** Bug 13388 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Per notes on bug 10422, there's also interest in being able to use the section > editing features for longer files. 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
There is a workaround in Javascript for creating the wikilinks in JS/CSS pages. See: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)#Script_for_wikilinks_in_CSS.2FJS_pages
(replacing blocker with the one it was marked duplicate of)
Is there any rule or convention that the _entire_ page contents be valid CSS/JS? Could you add a standardized format in the wikitext, but omit the irrelevant (non-JS or non-CSS parts) when outputting via &action=raw (which is the only reason I can see you'd need to have the entire page be valid CSS/JS)? For example, imagine this in the textarea. -------------------------------------- | == Header == | | Description text with [[wikilinks]]. | | ---- | | #id { | | display:none; | | } | -------------------------------------- This would allow for section-editing and wikilinks (for author attribution, etc.). Rendered, this would be something like... --- <h2>Header</h2> <p>Description text with <a>wikilinks</a>.</p> <hr /> <pre> #id { display:none; } </pre> --- It would output with this wikitext at action=edit and at the implicit action=view. But at action=raw, it would just output: --- #id { display:none; } --- Just a silly thought.
(In reply to MZMcBride from comment #15) > Is there any rule or convention that the _entire_ page contents be valid > CSS/JS? Could you add a standardized format in the wikitext, but omit the > irrelevant (non-JS or non-CSS parts) when outputting via &action=raw (which > is the only reason I can see you'd need to have the entire page be valid > CSS/JS)? > > … > > Just a silly thought. This is called [[literate programming]] and is in fact a reasonably serious concept. Maybe we want to implement support for some kind of "literate CSS" (we already have the internals for this implemented for LESS) and provide support for it in wiki pages (akin to bug 54864 for MediaWiki:Common.less etc.)?
