bugs wrote:

It would probably be better to create new skin-specific magic words for things like the user's current skin and the wiki's default skin. Then you could just use the existing ParserFunction and do something like {{#switch:{{CURRENTSKIN}}|monobook=bleh|#default=bleh2}}.

mathsmart9 wrote:

That actually is a good idea. I'll open a new bug request. Can you close this for me?

Since they're essentially asking for the same feature (or to solve the same usecase), and everyone who's commented seems to like the magic word method, its probably fine to just rename this. (which I just did)

As an aside, this feature sounds like something that would have a (possibly negative) affect on how caching works, but I don't really know enough about how parser cache works to comment on that.

(In reply to comment #3)

As an aside, this feature sounds like something that would have a (possibly
negative) affect on how caching works, but I don't really know enough about how
parser cache works to comment on that.

The parser cache code would have to be tweaked a bit such that a different version if cached for each skin if {{CURRENTSKIN}} is used on the page. I don't think that's terribly hard to do; Platonides would know, I think, CCing him. As for performance: I don't think it'd have a large impact as long as {{CURRENTSKIN}} isn't used on lots and lots of pages.

I am not convinced about the usecase for adding such parserfunction in core.

You want to give a slightly different style to a table (eg. footballer infobox) depending on the skin. Given how these things expand, this would ultimately lead to hundred of pages with skin variants.
However, there's another way to get the same effect which doesn't require splitting the cache: use a class in the infobox, then customize the styles in MediaWiki:Vector.css, MediaWiki:Monobook.css...

I don't think there will be too much use for message customization either. Take into account that internal messages can provide the skin as a parameter if needed, so only wiki instruction would need it.

However, it reduces reviewing. An addition of {{#ifeq:{{CURRENTSKIN}}|cologneblue | <profanity here> }} inside a biography would be hardly noticed unless viewing the wikitext, while still providing the vandal a way to advertise it using the useskin parameter.

Skin style customization via the skin css page, although harder for non-admins, is much safer.

mathsmart9 wrote:

Actually, shouldn't those already be detected by anti-vandalism tools/bots? It doesn't exactly matter whether or not it's in a #ifeq: or not. If it's not detected by anti-vandalism tools, it may be a bit harder to remove, but it shouldn't be too difficult for someone who searches up "<profanity here>" to remove it.

It may be possible to use MediaWiki:<skin>.css, but as a non-admin, it is a bit more difficult to make changes.

How would this respond when there's no skin? The only situations I can think of would be action=parse in the API and action=render via index.php, though parsed system messages might also be affected.

I agree with Platonides though, if the main use is styling, we have skin-specific CSS for this already. And when it comes to the English Wikipedia "they probably won't use it too much" is almost never a safe assumption.

It may be possible to use MediaWiki:<skin>.css, but as a non-admin, it is a bit
more difficult to make changes.

I am aware of such inconvenience, but despite of it, still seems a better system.

not it's in a #ifeq: or not. If it's not
detected by anti-vandalism tools, it may be a bit harder to remove, but it
shouldn't be too difficult for someone who searches up "<profanity here>" to
remove it.

Until you get that profanity included in a template included only for a few uncommon skins from a template three levels deep. Which makes me thing, including links or templates under a {{CURRENTSKIN}} branch would produce another instance
into bug 14404.

mathsmart9 wrote:

(In reply to comment #7)

How would this respond when there's no skin? The only situations I can think of
would be action=parse in the API and action=render via index.php, though parsed
system messages might also be affected.

#default should be triggered if there is no skin, since it will not match any of the test cases.

That may seem logical to you, but the fact is, it would use your default skin.

This would fragment the cache even more. Imho something like this that fragments the cache with little extra purpose should be isolated to an extension.

Suggesting LATER or WONTFIX per the mentioned problems and complexity with parser cache and linking tables.

If the usecase is style, contact your wiki admin and ask him to add some css-classes to MediaWiki:Common.css.

The root tag of all MediaWiki-pages contains (among others) a class for the current skin.

<body class="mediawiki ltr ns-0 ns-subject page-Sandbox skin-vector">

so, something like the following should work fine if you really need something in the wiki to be skin-dependend. Add the following to MediaWiki:Vector.css

/* Make the table of contents white-on-black in Monobook! */
#toc { background-color: black; color: white; }

or if you have several different colors for different skins, it may be easier to keep them together, instead the following in MediaWiki:Common.css

/* Funky wikitables */
.mediawiki .wikitable td { background-color: black; /* default */ }
.skin-vector .wikitable td { background-color: #8da7d6 }
.skin-monobook .wikitable td { background-color: #00FF00 }

Or if you *really* need to switch the actual article contents (usecase example?) even this would work:

Template:SkinSwitch

<div class="skinswitch skinswitch-vector">{{{vector|}}}</div>
<div class="skinswitch skinswitch-monobook">{{{monobook|}}}</div>
<div class="skinswitch skinswitch-default">{{{default|}}}</div>

MediaWiki:Common.css
.skinswitch { display: none; }
.skinswitch-default { display: block; }

.skin-vector .skinswitch-default,
.skin-monobook .skinswitch-default { display: none; }

.skin-vector .skinswitch-vector,
.skin-monobook .skinswitch-monobook { display: block; }

User:Example

{{SkinSwitch

}}

Closing per Krinkle. The only use case presented is non-admin styling of templates, hovewer all popular templates on large wikis are protected anyway.