rowan.collins wrote:

I think the main argument against this is that the more styling you do in the
middle of the content itself, the less power the software and the site
administrators have over the styling of the site as a whole. For instance, by
specifying link colors, you override user settings, skins, and of course the
distinguishability of links to non-existent pages. And, of course, you risk
losing the "standard feel" of the site.

An alternative is to, as a community, come up with a set of standardised CSS
classes that can be used, and add them to the [[MediaWiki:monobook.css]] page.
Then, you can use <div class="whatever"> to activate one of these set styles,
but still keep them within agreed standards.

Just my €0.02

Gabriel.de-Perthuis wrote:

I agree there is a consistency issue.
I think that a good policy is to use this:

• only in navigation templates, these are pages in the pages;
• always using a #WName_of_the_template selector;
• and asking people to specify colors for at minimum:

html, body {

background: #fff;
color: #000;

}

a:link {

background: #fff;
color: #037;

}

a:visited {

background: #fff;
color: #636;

}

• from http://www.w3.org/QA/Tips/color

To make it more foolproof, it could be made into a template:
{{CustomColoursTemplate|fg|bg|a_fg|a_bg|a_visited_fg|a_visited_bg}} .
Most people wouldn't dare use such a thing without reading the explanation.

Currently the consistency issue isn't addressed, since the templates I see
hardcode some colors and leave the link colors untouched, thus clashing with
stylesheets that have non standard link colors.

Gabriel.de-Perthuis wrote:

Expanding a bit on what the template should do exactly:
take 6 colors, take the including page name;
surround the wiki text of the including page in a <div
id="WName_of_the_including_page"> ;
add a <style> tag to the rendered page (not the same as the including one, since
this is meant for navigation templates), where each declaration is protected by
a #WName_of_the_including_page selector.

avarab wrote:

So you basically want:

• A <style> tag that does all the @media stuff for you
• A <div id=" where the id is the page name

?

Gabriel.de-Perthuis wrote:

I've put up an example here:
http://fr.wikipedia.org/wiki/Utilisateur:OnyxG7/exp%C3%A9rimentation
includes this navbar:
http://fr.wikipedia.org/wiki/Mod%C3%A8le:Mod%C3%A8leColoris%C3%A9
the navbar includes this template that applies custom colors to it:
http://fr.wikipedia.org/wiki/Mod%C3%A8le:Colorisation&action=edit
The color applier needs the <style> tag.
Or the color applier could be written as a tag instead of a template, so as not
to expose the <style> tag.

Besides the <style> tag, automatically wrapping a template in <div
id="W_TEMPLATENAME"> and defining {{TEMPLATENAME}} to work similar to
{{PAGENAME}} makes it cleaner, but isn't necessary.

ayg wrote:

In principle, admins can add classes to the CSS, but in practice that tends to
happen very slowly. The advantage of allowing <style> would be the potential
for slightly more compact and semantic code; it would be good to have the site
stylesheets override the <style> declarations, though (by putting the <style>
contents into their own stylesheet, rather than into an actual <style> tag, and
by banning !important), to prevent monkey business. It could thus be used only
to create styles for classes/ids that don't have a centralized style, and upon
subsequent addition of that style to the main stylesheet it would be maintained
centrally for a coherent look.

Achieving the former would be tricky, however. It wouldn't be hard to add a
selector more specific than those in the main stylesheet: for instance,
"#globalWrapper p" is more specific than "p" and would override it, even if it
was declared previously. If we don't want anyone screwing with the interface,
we'd have to maintain a list of all classes and ids used in the interface and
main stylesheets, as well as parsing all selectors correctly, and also
incorrectly to deal with any known browser bugs. The result would be that you
could only use selectors that include non-site-wide classes or ids, which would
prevent you from messing with the interface.

So this is possibly doable but quite involved, alas (how are you going to
maintain the list of global classes/ids?).

ayg wrote:

(In reply to comment #3)

surround the wiki text of the including page in a <div
id="WName_of_the_including_page"> ;
add a <style> tag to the rendered page (not the same as the including one, since
this is meant for navigation templates), where each declaration is protected by
a #WName_of_the_including_page selector.

Oh, hmm. That's clever. Why didn't I spot that comment before? This should
work quite well. May as well make the prepended id with #content, however, to
allow <style> to modify the entire content if desired.

Let me see if I can't work on this . . .

This can be done with the CSS extension:

http://www.mediawiki.org/wiki/Extension:CSS

Though we don't have this enabled on Wikimedia sites at present. On a quick look, there may be security issues with it.

With this feature we could also create per-book templates to workaround the (two years old) bug 15075.

happy.melon.wiki wrote:

Functionality like Extension:CSS is definitely the way to implement this; since it's available, this bug is FIXED. You should open a separate one if you want it installed on WMF wikis.

Note you can also use CSS on [[MediaWiki:Common.css]] of your wiki and use those classes and selectors throughout your wiki.