Last modified: 2014-05-05 17:46:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10410 - Render wikilinks in site/user CSS/JS
Render wikilinks in site/user CSS/JS
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 13388 (view as bug list)
Depends on:
Blocks: css 10422 32858
  Show dependency treegraph
 
Reported: 2007-06-29 17:05 UTC by Carl Fürstenberg
Modified: 2014-05-05 17:46 UTC (History)
9 users (show)

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


Attachments
look how it's looking (40.86 KB, image/png)
2007-06-29 17:05 UTC, Carl Fürstenberg
Details

Description Carl Fürstenberg 2007-06-29 17:05:55 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-29 17:30:20 UTC
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?
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-29 17:32:03 UTC
(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.)
Comment 3 Brion Vibber 2007-06-29 18:21:42 UTC
(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.
Comment 4 Tisza Gergő 2007-07-01 07:27:53 UTC
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
Comment 5 Carl Fürstenberg 2007-07-02 00:45:36 UTC
(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.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-02 00:51:04 UTC
Resolved with fix for 10422.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-02 23:26:40 UTC
Fix for bug 10422 rolled back per Brion at bug 10422 comment 10, reopening.
Comment 8 Brion Vibber 2007-07-03 19:52:29 UTC
Per notes on bug 10422, there's also interest in being able to use the section editing features for longer files.
Comment 9 Danny B. 2007-07-17 23:58:36 UTC
Hardcoded syntax hilite behavior is not user friendly. I suggest different approach in bug 10621.
Comment 10 Danny B. 2007-07-30 19:34:12 UTC
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.
Comment 11 Brion Vibber 2008-03-17 22:22:00 UTC
*** Bug 13388 has been marked as a duplicate of this bug. ***
Comment 12 Helder 2011-01-09 17:25:16 UTC
(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
Comment 13 Helder 2011-01-09 18:11:21 UTC
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
Comment 14 Krinkle 2011-12-30 19:42:08 UTC
(replacing blocker with the one it was marked duplicate of)
Comment 15 MZMcBride 2013-03-02 06:40:15 UTC
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.
Comment 16 Bartosz Dziewoński 2014-05-05 17:46:23 UTC
(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.)?

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


Navigation
Links