Last modified: 2011-03-31 00:07:39 UTC
I'd like to customize a model (eg, a light on dark model for the link above), but I can't style it as much as I could with a style tag in the page head. It is possible to choose one element's style, using a style attribute, but it doesn't work for links (even if it would that would be tens of links to change instead of using a selector). «If you pick one color pick them all», as the w3c says - I can only change the background. I'd like to put: <style type="text/css" media="screen" title="WSerie_SF"> #WSerie_SF a { color: white; } </style> in the page and have it included in head when rendering.
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
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.
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.
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 ?
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.
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?).
(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.
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.
