| AzaToth | |
| Jun 29 2007, 5:05 PM |
| F4247: source.png | |
| Apr 13 2015, 2:37 PM |
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.
Look how it's looking:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T64559 Redesign Special:Preferences (tracking) | |||
| Open | None | T71550 Move code in enwiki MediaWiki:Common.js and Gadgets to MediaWiki software | |||
| Open | None | T12410 Render wikilinks in site/user CSS/JS |
ayg wrote:
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?
ayg wrote:
(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.
ayg wrote:
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.
(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
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;
}
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.)?
See https://en.wikipedia.org/wiki/User:Danski454/code-link for a script implementation
https://en.wiktionary.org/wiki/MediaWiki:Gadget-CodeLinks.js is another wonderful gadget implementation.