Page MenuHomePhabricator

Render wikilinks in site/user CSS/JS
Open, MediumPublic

Description

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:

Details

Reference
bz10410

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:54 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz10410.
bzimport added a subscriber: Unknown Object (MLST).
AzaToth created this task.Jun 29 2007, 5:05 PM

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

brion added a comment.Jun 29 2007, 6:21 PM

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

Tgr added a comment.Jul 1 2007, 7:27 AM

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:

Resolved with fix for 10422.

ayg wrote:

Fix for bug 10422 rolled back per Brion at bug 10422 comment 10, reopening.

brion added a comment.Jul 3 2007, 7:52 PM

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. ***
He7d3r added a comment.Jan 9 2011, 5:25 PM

(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

He7d3r added a comment.EditedJan 9 2011, 6:11 PM

There is a workaround in Javascript for creating the wikilinks in JS/CSS pages.

See https://github.com/he7d3r/mw-gadget-LinksOnJSPages.

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

Aklapper added subscribers: Omar_Ghrida, Aklapper.

@Omar_Ghrida: I don't see what this has to do with Front-end-Standards-Group at all?

Restricted Application added a subscriber: alaa. · View Herald TranscriptDec 3 2020, 2:26 PM