Archive 1 ← Archive 3 Archive 4 Archive 5

Light blue background colour

Having the light blue background colour on all non-namespace pages makes the categories page look a bit rubbish. The Category trees and lists have white backgrounds, but the rest of the page is light blue. Also any transparent images on their images page obviously show the bg as light blue, which isn't always a problem, but normally looks nicer in white. I don't really see any need for having these with light blue. Chris_huhtalk 11:11, 20 December 2007 (UTC)

The comment above is now a bit old, but I'll answer it anyway for future reference:
That the category lists are white is kind of a bug, we are just about to fix that. See section Default table colours below. And the transparent images no longer have blue background, instead they now have a special grey-white chequered background to make it clear that they are transparent images.
--David Göthberg (talk) 23:22, 29 August 2008 (UTC)

pre { overflow: auto }

I'd like to bring back an earlier discussion which suggested that monobook/main.css uses the following property for the <pre> tag:
overflow: auto
so that <pre> sections look nicer in some web browsers when they contain long lines of text (an example: sudo). -- Rpremuz (talk) 17:37, 1 January 2008 (UTC)

Not all browsers support "overflow: auto;". Thus if people don't see when they put too long lines in the pre boxes since their browsers do support "overflow: auto;" then they will make pages that gets seriously unreadable for those browsers that don't support "overflow: auto;". We have experienced that before and that is a real problem.
And your sudo example is exactly a case where the page editors can choose to instead line wrap the text, after all that long text is just a log file which would be line wrapped when viewed in most systems.
And I think horizontal scroll bars are ugly and don't belong on the pages. I prefer to use the scroll bar at the bottom of the page.
--David Göthberg (talk) 23:36, 29 August 2008 (UTC)

plainlinks2

Random832 has added the following class 

/* allow disabling of "external" color on internal links in some situations */
#bodyContent .plainlinks2 a.external[href^="http://en.wikipedia.org"] {
	color: #002bb8 !important
}

I suggest that we simply make all external links in the plainlinks class which point to /w/ directory are the wikilink blue. Bellow is my renderition of the code with a few improvements. 

#bodyContent .plainlinks a[href ^="http://en.wikipedia.org/w/"] {
	color: #002bb8 !important;
}

I assume that his edit was connected with the new modern skin having a different color for interwiki links. This coloring seem somewhat desirable as ((tnavbar)) have hard coded that color. The downsides to this maybe that it makes it hard for people to easily see editing links. —— Dispenser 00:57, 30 January 2008 (UTC)

My intention was to use this class for the links in ((userlinks)) and its siblings that people insist on putting <font color...> tags on, without affecting the usage for other links like editing links. —Random832 (contribs) 19:25, 24 March 2008 (UTC)

Light BG fix

Resolved.

((editprotected)) 

body.ns--1 table, form table {background: transparent}

/* Give transparent background to table on confirm deletion page */
form#deleteconfirm table {
    background-color:transparent;
}

—AlexSm 15:20, 20 March 2008 (UTC)

This should be unnecessary when r32270 goes live. Mr.Z-man 23:10, 20 March 2008 (UTC)
And plus rev:32269, which actually fixes it for RC/Watchlist. Let's not make any more extra edits and wait for that revision, so when CURRENTVERSION = 1.43.0-wmf.5 (58d6360) reaches r32270, the section between /* BEGIN LIGHT BLUE SECTION */ and /* END LIGHT BLUE SECTION */ can be replaced with the code below ("body.ns--1 table, form table" removed, some identical rules combined). —AlexSm 15:39, 21 March 2008 (UTC)
/* Make content area light blue in all namespaces except articles (main namespace) */

#content,
#p-cactions li a, #p-cactions li a:hover, #p-cactions li.selected a {
  background-color: #F8FCFF; /* a light blue */
}
#content div.thumb {
  border-color: #F8FCFF;
}

.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
  background-color: white;
}
.ns-0 * #p-cactions li a {
  background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
  border-color: white;
}
 Done. Still get white backgrounds in diffs though. Happy‑melon 21:28, 24 March 2008 (UTC)
That's a table, and personally, I prefer it white. — Edokter • Talk • 22:22, 24 March 2008 (UTC)
Seems all this has been fixed now. My latest edits took care of the only remaining cases: The category lists and the diffs are now transparent too. --David Göthberg (talk) 13:45, 1 September 2008 (UTC)

Light blue background

darker non-main background
#F0FAFF

non-main background
#F8FCFF

mainspace-background
white

I don't really see the point of having non-article pages have a different color background. Most people don't realize there's a difference at all. For those who do, it doesn't really provide much. Would there be any objection to removing it entirely? Should we keep the mainspace different to the other namespaces, or make them all white? Happy‑melon 18:16, 25 March 2008 (UTC) --MZMcBride (talk) 04:04, 25 March 2008 (UTC)

  • I've posted something on the VP to attract more attention. Hersfold (t/a/c) 18:01, 25 March 2008 (UTC)

Base font size

This is not so much related to monobook.css, rather then to monobook/main.css, which does not have a talk page.
Test page: User:Edokter/fonttest

I have been racking my brain over why different browsers show different base font sizes, ofter correcting fontsize in different templates to make them look the same in most browsers. I did some tracing and finally found the root of the problem... litterally. /skins-1.5/monobook/main.css has the base BODY font declared as FONT: x-small sans-serif, only to be upscaled to 127% again in the globalWrapper div declaration. Using x-small is a very bad starting point, as each browser handles it differently. Playing with overriding these values (by using a fixed value instead), I found that consistency between browsers is indeed possible.

Would it be desireable to file a bugzila request to have it changed so that it uses only one base font declaration (62% in the body) instead? What are other's thoughts? — Edokter • Talk • 18:01, 17 April 2008 (UTC)

I'd like to see some extensive testing across different browsers and versions first. The current "x-small" trick was presumably introduced deliberately, precisely to ensure consistent rendering across different browsers. If it no longer reliably delivers that, it indeed ought to be fixed, but let's try to be careful not to break more cases than we fix. Note that monobook/main.css contains a comment referencing http://www.w3.org/QA/Tips/font-size (archive link) and http://style.cleverchimp.com/font_size_intervals/altintervals.html — I've only glanced at those pages so far, but presumably they contain information which should be kept in mind while considering this issue. —Ilmari Karonen (talk) 18:44, 19 April 2008 (UTC)
That is some interesting reading, which actually confirmed my suspicion that choosing a key-word for a base font size is a terrible idea. In fact, the first document strongly advises against it. I don't know in which era Monobook was created, which CSS revision was leading at the time etc., but I think we need to revise Monobook somewhat so that it is fully CSS2 compliant. Of course, we'd need to know how it was intended to look like... Who designed it, and what browser was (s)he using? — Edokter • Talk • 19:03, 19 April 2008 (UTC)
It looks like someone was just too lazy to define the fontsize for all content outside globalWrapper. I agree, this is bad and needs to be fixed. --TheDJ (talk • contribs) 19:23, 19 April 2008 (UTC)
Umm... in Monobook, there is no content outside #globalWrapper. Presumably that div was introduced specifically for this font-scaling trick. —Ilmari Karonen (talk) 19:42, 19 April 2008 (UTC)
Never the less, the font defined in the base HTML element affects everthing inside it; including globalWrapper. — Edokter • Talk • 20:51, 19 April 2008 (UTC)
I'm not really sure if you're agreeing or disagreeing, but anyway... the current setup, with the font size set to "x-small" for body and "127%" for #globalWrapper means that everything inside #globalWrapper — that's everything on the page, since #globalWrapper is the only direct child of the body element — has a font size of "x-small × 127%". There's no way to specify such a font size in a single CSS declaration, which is presumably why the wrapper element exists. —Ilmari Karonen (talk) 12:03, 20 April 2008 (UTC)
It is actually the root of the inconsistency; x-small is calculated differently between browsers (and apparently, acts differently on monospaced fonts). One possible solution that I have now in my monobook.css is to set the globalWrapper font-size to 125%; this triggers IE to show all fonts just like Firefox, while not having any noticable effect in Firefox. That is becuase a lot of fonts are set to 90%, which balances exactly between two font rendition between IE and Firefox. Up until now, I have been changing those fontsizes to 88% when I come accross them, but setting the global fontsize to 125% also works. — Edokter • Talk • 13:09, 20 April 2008 (UTC)

Anyway, it should be possible to test Edokter's suggestion by adding 

body.mediawiki { font-size: 62.5% }

into your monobook.css. What we really need here is a side-by-side comparison of screenshots from as many browsers as possible, including old and esoteric ones (cellphone browsers, anyone?), with different screen resolutions and default font sizes. —Ilmari Karonen (talk) 19:46, 19 April 2008 (UTC)

Hmm... just did that; curiously, everything else stayed exactly the same, but preformatted text got a lot smaller. Now what's the deal with that? (Browser: Firefox 2.0.0.13 / Gecko 20080325 on Kubuntu Linux) —Ilmari Karonen (talk) 19:54, 19 April 2008 (UTC)
I've made a simple test page and uploaded a screenshot. More screenshots would be welcome. —Ilmari Karonen (talk) 23:42, 19 April 2008 (UTC)
That's a known problem with Gecko, see "Monospace, Firefox and braindeath". —Ms2ger (talk) 08:39, 20 April 2008 (UTC)
I am not sure if this is related, but the font on my computer in Mozilla Firefox looks weird (really not nice to look at!). See screenshot --Ghormax (talk) 14:34, 13 January 2009 (UTC)
I do not think it's related; your computer seems to be missing some core fonts. — Edokter • Talk • 15:09, 13 January 2009 (UTC)
I do not know what the problem was but it has returned to normal! In any case, it was not a problem of missing fonts. --Ghormax (talk) 09:43, 28 January 2009 (UTC)
I'm using the latest Safari/Mac, with a lot of custom CSS in my user style sheet. With the body.mediawiki declaration, the test page remains identical to the pixel. —Michael Z. 2009-01-28 15:32 z

Padding for the "+ / new section" tab.

Per discussion at Wikipedia:Village pump (proposals)#Replace "+" with "add new comment" the talk page add section tab "+" was renamed to "new section". (See the top of this page for an example.) That means that it needs the same padding as the other tabs. Thus I added this code today: 

#p-cactions #ca-addsection a {
	padding-left: .8em;
	padding-right: .8em;
}

Note that this code really belongs here and should not be moved to Common.css. To see the new correct padding you might need to refresh your web browser cache. This is due to that MediaWiki:Monobook.css is set to be cached in web browsers for 30 days.

--David Göthberg (talk) 22:01, 19 April 2008 (UTC)

Admittedly the very first thing I did upon noticing this was alter my JS to swap it back to a '+', but hopefully the change is helpful for new users who may not intuitively grasp the meaning of the symbol. :) – Luna Santin (talk) 23:17, 19 April 2008 (UTC)

Proposed code addition

I'm proposing the addition of 

ul.permissions-errors > li {list-style: none;}
ul.permissions-errors {margin:0}

to Monobook.css in order to remove the bullets in front of the protection messages. Thoughts? --MZMcBride (talk) 00:38, 3 May 2008 (UTC)

I suggest we better ask developers to fix that. —AlexSm 03:16, 3 May 2008 (UTC)
They're the ones who implemented the bullets. I've asked previously; "they" said to use CSS to remove the bullets. --MZMcBride (talk) 03:19, 3 May 2008 (UTC)
Umm...however, > is not going to work in IE6. Also, I seem to remember that list-style:none; might not be enough for some browsers (maybe IE again)? And the weirdest thing that it's currently <div class="permissions-errors"> on another project. —AlexSm 04:23, 3 May 2008 (UTC)
But it won't break IE, right? IE6 can barely generate plain text. As long as it won't cause harm elsewhere, I see no reason to not remove the bullets. The reason for a <div> on another project is most likely due to the way the code is generated -- if there are two messages, it uses a <ul>, if not it uses a <div>. ... or something like that. And admins get a much different view than non-admins on protected &action=edit pages. --MZMcBride (talk) 05:03, 3 May 2008 (UTC)

siteNotice changes

I've removed padding-left:4px from the siteNotice id. It was added years ago, and doesn't serve any particular purpose. I also changed the margin-bottom of the siteNotice to -.5em. Negative margins should degrade gracefully in older browsers. The change was made to offset the <h1> padding in main.css. Let me know if there are any issues. Cheers. --MZMcBride (talk) 04:05, 7 May 2008 (UTC)

When I view Wikipedia when not logged in, then the sitenotice comes too close to the small "• Ten things you may not know about Wikipedia •" notice. (Well, the text in that notice changes all the time, don't know what that notice is called.) I have the same problem in all three of my browsers: Firefox 2.0, Opera 9.0 and IE 5.5. So seems the sitenotice needs more top margin. The top margin problem is not your fault since you didn't change that, but it needs fixing. It seems that the "Ten things" notice is added by javascript since I can not see it in the HTML source of the rendered page.
And currently we have too many notices on top of the pages for not logged in users: We have the donate notice, the "ten things" notice, and the sitenotice. That is too much. Looks messy.
--David Göthberg (talk) 22:50, 8 May 2008 (UTC)
Also, the narrower you make the browser window, the uglier it looks. Bottom banners overlap each other, top banner overlaps with "Log in / create account" message. Also, Wikimania banner for anons? very weird; but that's been already discussed somewhere else. —AlexSm 23:34, 8 May 2008 (UTC)

monobook on every website

is there a way I can use Stylish to give every site i view wikipedia's monobook skin. – ThatWikiGuy (talk) 20:48, 8 May 2008 (UTC)

Most websites don't have the same structure, so no unless the site itself has a monobook-lookalike skin written for it. --Random832 (contribs) 03:56, 9 May 2008 (UTC)
OK,If I could design my dead scribblewiki site to how I want google, could you base the stylish skin on that? For google? – ThatWikiGuy (talk) 20:47, 9 May 2008 (UTC)
Half-designed, added notes to guy on mainpage. Ready. Thank you. – ThatWikiGuy (talk) 21:29, 9 May 2008 (UTC)

Category height

A couple months ago, the category height was changed. What affected this? How can I can I emulate the change on my own wiki? A response on my talk page would be quite appreciated. Thanks. --Emesee (talk) 00:16, 16 May 2008 (UTC)

Default table colours

Resolved. - Kind of. --David Göthberg (talk) 13:50, 1 September 2008 (UTC)

I have noticed that the default table background in the monobook skin is white. (That is, for plain tables that don't set any colours or don't use the "wikitable" class and so on.) And since we use a slight blue background in all namespaces except main (article) space then the tables get a visible white background on all those pages. Like this: 

{| 
| Cell 1
| Cell 2
|}

Which at the moment renders a table with a white background:

Cell 1 Cell 2

This also gets very visible on category pages, since the lists with subcategories and pages are built with tables. See any non-empty category page for that, for instance Category:Wikipedia maintenance.

The white table background was added long ago to monobook/main.css to prevent that other content bleed through when a table overlaps it. For instance when a right floating table overlaps the bottom border of a level two heading. I think I agree with that fix.

However, we should of course make the fix work right for our light blue pages. Thus I want to add this code to the "LIGHT BLUE SECTION" of MediaWiki:Monobook.css: 

#content table {
    background-color: #F8FCFF;    /* Light blue */
}
.ns-0 #content table {
    background-color: white;    /* Set back to white for articles */
}

I have of course tested this in my personal /monobook.css.

While I am at it I would like to remove all the unnecessary * in that section. That is change this: 

.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
    background-color: white;
}
.ns-0 * #p-cactions li a {
    background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
    border-color: white;
}

To this: 

.ns-0 #content,
.ns-0 #p-cactions li.selected a, .ns-0 #p-cactions li a:hover {
    background-color: white;
}
.ns-0 #p-cactions li a {
    background-color: #FBFBFB;
}
.ns-0 #content div.thumb {
    border-color: white;
}

Or am I missing something?

--David Göthberg (talk) 15:55, 29 August 2008 (UTC)

Why not set
#content table {
    background-color: transparent;
}
instead? That would be much simpler and more reliable than setting it to the current background colors for article and non-article pages. —Remember the dot (talk) 16:35, 29 August 2008 (UTC)
Right, your code also works. But as I described above:
"The white table background was added long ago to monobook/main.css to prevent that other content bleed through when a table overlaps it. For instance when a right floating table overlaps the bottom border of a level two heading."
Of course, if tables overlap then you have bad page layout and it is merely a matter of personal preference if the content below the table should then bleed through or not. Both are bad: To hide the content is bad, and to show it so you still to some extent can read it usually looks very messy. I merely made my code in a way that would retain the currently deployed fix. But I am okay with transparent too.
--David Göthberg (talk) 17:15, 29 August 2008 (UTC)
The inactive tabs in articles are slightly darker. I find that a good subtle cue and it looks good. I would like to do the same to the inactive tabs on the other pages. I have experimented a little with the colours and the result was the light gray-blue #F7F9FB;. So I would like to add this code:
#p-cactions li a {
    background-color: #F7F9FB;   /* Light blue-gray tabs for other pages */
}
With the table fix from above and the slightly darker tabs for "other pages" that makes my whole code suggestion for the "LIGHT BLUE SECTION" look like this:
#content,
#p-cactions li a:hover, #p-cactions li.selected a,
#content div.thumb, #content table {
    background-color: #F8FCFF;   /* Light blue */
}
#p-cactions li a {
    background-color: #F7F9FB;   /* Light blue-gray inactive tabs */
}
 
.ns-0 #content,
.ns-0 #p-cactions li a:hover, .ns-0 #p-cactions li.selected a, 
.ns-0 #content div.thumb, .ns-0 #content table {
    background-color: white;     /* Set back to white for articles */
}
.ns-0 #p-cactions li a {
    background-color: #FBFBFB;   /* Light gray inactive tabs in articles */
}
--David Göthberg (talk) 01:01, 30 August 2008 (UTC)
Gah! Since no one commented for a day I deployed my code above. In spite that I had tested it in my own monobook.css it caused problems. So I immediately reversed myself.
Silly me, I should have realised. We can not add the changes to the table colours like I did. Since I selected the tables with "#content table" and ".ns-0 #content table" to avoid selecting any tables in the user interface outside the page area. But that gives that selectors the specificity points 1.0.1 and 1.1.1, which wins over pretty much any other table declarations, no matter if they are declared before or after. (Like all the mbox and message box tables in MediaWiki:Common.css.) This also means we can not set the tables to transparent background like this either, since then all other tables will be transparent too.
So I need to think about where and how to add that fix.
But the code that made the inactive tabs light blue-gray seemed to work fine. I still plan on adding that.
--David Göthberg (talk) 16:58, 31 August 2008 (UTC)
I have now added the code that makes the inactive tabs light blue-gray.
I have also added code that makes the category lists and diffs transparent instead of white. For diffs on article pages this makes no difference but diffs on other pages now look better. There were no good way to override the "table overlapping fix" in monobook/main.css for all table uses, so instead I had to override for each of the cases I am aware of. We should consider if that "table overlapping fix" perhaps simply should be removed.
--David Göthberg (talk) 01:36, 1 September 2008 (UTC)

Image gallery colours

Currently images in galleries in articles get white padding, and transparent images get white background.

And when galleries are shown on non-article pages the images get light blue padding, and transparent images get light grey background. This is so both for galleries made with the gallery tag and automatic galleries on category pages. An example is Category:Wikipedia image placeholders which has many transparent images.

I intend to change the colours to this instead:

1: Galleries in articles, user pages and portals should get light grey padding, and transparent images should get white background. This is slightly toned down compared to the current white padding, and it helps seeing the actual borders of transparent images.

2: Galleries on other pages, such as category pages, also should get light grey padding. But transparent images should get chequered background, with fall-back to white background if the chequered background image does not load.

The chequered background makes it easy to see which images are transparent and what parts of the images are transparent. I intend to use a softened version of the chequered background that is currently used on image pages, since I think the current version interferes too much with the images.

Since the chequering is slightly ugly I don't want to use it on articles, user pages and portals. I expect that most editors want good looks before function on such pages.

Here is the code for all that: 

/* Setting the backgrounds for galleries. */
#content .gallerybox div.thumb {
    background-color: #F9F9F9;   /* Light gray padding */
}
.gallerybox .thumb img {
    background: white url("http://upload.wikimedia.org/wikipedia/en/a/a2/Checker-soft.png") repeat;
}
.ns-0 .gallerybox .thumb img,      /* Articles */
.ns-2 .gallerybox .thumb img,      /* User pages */
.ns-100 .gallerybox .thumb img {   /* Portals */
    background: white;   /* No chequered background */
}

I just noticed that Commons have set their galleries to the same colours and a chequered background. And they have set it for all their skins by placing it in MediaWiki:Common.css, I think we should do the same.

--David Göthberg (talk) 03:21, 1 September 2008 (UTC)

checkY Done - Added the code above to MediaWiki:Common.css, and cleaned away a code snippet here that then isn't needed anymore. Now galleries are looking very nice in all namespaces.
--David Göthberg (talk) 22:22, 1 September 2008 (UTC)

Template:Spoken Article

There is no ((Spoken Article)) please remove refence to it in the absolute section, or replace it with a template like ((template:Coord)) Odessaukrain (talk) 14:33, 20 October 2008 (UTC)

I assume you mean the comment above the CSS selector "div.topicon" in MediaWiki:Monobook.css, right?
Note that ((coord)) instead uses the CSS id "coordinates", not the class "topicon".
The comment you are referring to is just missing an "s", as in "spoken articles" instead of "Spoken Article". Since ((spoken articles)) redirects to ((Spoken Wikipedia)) which in turn uses ((Spoken Wikipedia boilerplate)) which uses the class "topicon" for placing the little grey loudspeaker icon in the top right corner of the pages. I guess the templates have been somewhat reworked since that comment was written.
Here is the current comment:
/* For positioning icons at top-right, used in Templates
   "Spoken Article" and "Featured Article" */
We could perhaps change it to the more generic:
/* For positioning icons at top-right, used in
   spoken article and featured article templates. */
But I don't really see a need to change the comment.
--David Göthberg (talk) 18:16, 20 October 2008 (UTC)
IMO, it would be better to update the comment, but it can wait. —Ms2ger (talk) 19:33, 20 October 2008 (UTC)

Sitenotice background

The MediaWiki:Sitenotice (currently with the message "Help shape the future of Wikipedia...") has a visible white background, when shown on other pages than articles when using the Monobook skin. This is a side effect of the light blue background in Monobook on "other pages" combined with the setting to use white background as default for tables in monobook/main.css.

Only logged in users see this at the moment. Since currently there is a MediaWiki:Anonnotice with the same content that overrides the sitenotice for the IP users, and the anonnotice is transparent.

Also, the current CSS for the sitenotice has two oddities:

1: It has a "background-color: transparent;" setting for the <div> element, which as far as I understand is unneeded and has no effect. (It is the <table> element that needs to be set to transparent.)

2: Its comment states that it should only "be uncommented during fund-raising drives". That's not good since due to the CSS caching it takes 31 days before all users see a change in these CSS files. Thus such "uncommenting" would have to be done 31 days before a fund-raising drive. Besides, the sitenotice is used for more than just fund-raising.

Here is the current code in MediaWiki:Common.css: 

/* Donations link to be uncommented during fund-raising drives  */
#siteNotice {
    margin-top: 5px;
    margin-bottom: -.5em;
    text-align: center;
    background-color: transparent;
}

I intend to change it to: 

#siteNotice {
    margin-top: 5px;
    margin-bottom: -.5em;
    text-align: center;
}
#mw-dismissable-notice {
    background: transparent;
}

I have tested it in my user space.

--David Göthberg (talk) 14:05, 29 October 2008 (UTC)

I was just coming here to suggest the exact same thing !!! :D The change from background-color -> background is also a good idea, because i believe IE does not support the earlier combination. --TheDJ (talk • contribs) 14:44, 29 October 2008 (UTC)
text-align:center simply duplicates the rule in skins-1.5/monobook/main.css. —AlexSm 16:02, 29 October 2008 (UTC)
AlexSm: Ah, thanks for spotting that one. I too spotted and fixed some things when I wrote the message above, so it is a good thing to announce like that before doing a change.
I just realised what the old comment "/* Donations link to be uncommented during fund-raising drives */" is about. It is not about the declaration immediately below it, but about the declaration one step further down:
/*
#fundraising {
    text-align: center;
    border: 1px solid gray;
    padding: 5px;
}
*/
However, having the "#fundraising" declaration remarked away seems silly to me for two reasons: One is that as I stated above we have the 31 days CSS caching. The other is that MediaWiki does not strip away comments before sending the CSS code to the web browsers, so remarking away a code snippet actually causes more bytes to transfer, not less.
So, here is the new version of the code I intend to add:
/* For sitenotice and fund-raising messages. */
#siteNotice {
    margin-top: 5px;
    margin-bottom: -.5em;
}
#mw-dismissable-notice {
    background: transparent;
}
#fundraising {
    border: 1px solid gray;
    padding: 5px;
    text-align: center;
}
I have only seen a very old version of the code used for the fund-raising, but it indicates that we should perhaps not remove the "text-align: center;" code for the "#fundraising" declaration.
--David Göthberg (talk) 19:11, 29 October 2008 (UTC)
I'm not sure the #fundraising code is needed at all. I don't think we still use that id. --MZMcBride (talk) 20:44, 29 October 2008 (UTC)
MZMcBride: Yeah, when I looked in the history of MediaWiki:Sitenotice I only found the "fundraising" id used two years ago. But I only did a very quick check in that history list. And everything that id supplies can just as well be coded into the message code when it is created, since nothing of it seems skin specific. So we can probably just remove that id.
--David Göthberg (talk) 20:55, 29 October 2008 (UTC)
checkY Done - I have updated MediaWiki:Monobook.css. And it looks fine in all three of my browsers, both when logged in and not logged in.
--David Göthberg (talk) 21:21, 29 October 2008 (UTC)

text-align: justify; override for infobox

Untitled
Untitled

Infoboxes are using text-align: justify;, inherited from #article, #bodyContent, #mw-content.

Justification doesn't look well on such narrow columns and adding <br /> is needed to make text look good.

Is it possible to add text-align: left; for .infobox to avoid such ugly spacing? See examples to the right, they are speaking themselves. —Preceding unsigned comment added by Angryxpeh (talk • contribs)

You use the "justify paragraphs" preference setting, don't you? Try turning it off and you'll understand why I didn't get what you were talking about at first. I agree it should be fixed, but be aware that it's not applicable to the majority of users. And there are many places other than infoboxes which shouldn't be justified; I think we should rather be saying, "is there anywhere other than the main page content that should be justified"?? Happy‑melon 14:54, 2 December 2008 (UTC)
Ah, that explains the whole thing. Thanks for pointing it out. Maybe "Justify paragraphs" should work for paragraphs only: <p>, <blockquote>, maybe <li>, <dd>? -- Serguei Trouchelle (talk) 16:55, 2 December 2008 (UTC)

Math font-size

In MediaWiki talk:Common.css#Request to fix size of Tex equations for html (simple equation) mode, some discussion has been going on wether to have HTML rendered LaTeX formulas the same size as the PNG rendered formulas. There has been no satisfiable outcome, as it is impossible to force static font sizes in some browsers.

What is appearent, and what started the discussion in the first place, is that the HTML rendered formulas (which are primarely used in-line) are too small, due to them using 'serif' as a font, and that doesn't mix well with Monobook's sans-serif. I would like to fix that with adding the below code, making the HTML formulas match in size with the rest of the text. That means that would become . I would like to do so in all skins using a sans-serif font (Chick, Cologne Blue, Modern and Monobook). Thoughts? — Edokter • Talk • 21:46, 24 May 2009 (UTC) 

.texhtml {
  font-size: 125%;
  line-height: 1.5em;
}
As there seems to be no objection, I will add it for evaluation and await community response, although I expect very little, if any at all. — Edokter • Talk • 17:11, 25 May 2009 (UTC)
Unfortunately the inline equations become too big for me and affects the spacing of the lines. When I proposed this idea I did not know that the ((math)) template would be affected by the change. The math template is designed for inline equations as it states and should be the same size as the text. What was bothering me was that <math></math> uses the same class in simple mode. The tex mode <math></math> use of this class "texhtml" needs to agree with pngs while ((math)) needs to agree with the font size. There is no way to compromise here I am afraid. We need another angle of attack to this problem it seems. TStein (talk) 21:22, 1 June 2009 (UTC)
I beg to differ; simple <math> does not need to match the PNGs, as simple math is ususally used inline, just like ((math)). We already established it is impossible to set a fixed font size. I went to great lengths in finding the right font sizes for each skin and tested that in several browsers; HTML math, wether used with <math> or ((math)), should have the same font-height as the surrounding text. If it doesn't, something in your monobook may interfere, or you have a non-standard font set (What OS/browser do you use?) Either way, consider that this change is intended to fix the display issue for most users; I am hesitant to revert because it does not look right on only your screen. It is the default mode for TeX to use HTML for simple formulas. However, you can simply set your preference to always use PNGs for math. — Edokter • Talk • 22:41, 1 June 2009 (UTC)
It really is not that much of an issue to me whether or not you revert this. (I am using the latest version of firefox by the way with XP; I don't know which font it is choosing, though since the style files choose a generic font it could be anything.)
There is no css solution as I stated above but I disagree strongly with the idea that inline <math> statements should be rendered the same as the text. According to the math manual of style inline use of <math is discouraged for a number of good reasons including rendering issues. We should not bust the separate line <math> statements for something that is discouraged and not necessary. Inline formulas should either be written directly in html or use \textsize or \scriptsize with the math mode.
Finally, setting the preference to a non-common setting defeats the purpose of an editor. I want my settings to reflect the most common setting so I can fix the most common bustage. TStein (talk) 23:25, 1 June 2009 (UTC)

Improving light-on-dark (green on black)

As OLEDs become more popular, many people will use this setting to save energy. (I use it, and for the most part, it's fine. The main problem is folks with colored signatures that come up as black on black.) But most templates set the background to white, while not setting the foreground (color:) to black (or something other than light green, which is hard to read on a white background. What's the best way to fix this? Should a bot go and edit all templates that set background to white but don't set foreground? Should (could) a bot go and edit (or flag) all signatures that are black on default? Or is there a smarter way? (Edits like this seem pointless.--Elvey (talk) 18:46, 31 May 2009 (UTC)

You're talking about the gadget, right? That's an issue with the gadget's stylesheet, and needs to be addressed there. (BTW, how did that get to be a gadget, anyways? I can think of far less problematic CSS stylesheets that would make far better gadgets than this...) ···「ダイノガイ千？！」? · Talk to Dinoguy1000 21:09, 1 June 2009 (UTC)
Right. Thanks for pointing me in the right direction. I also find light-on-dark easier to read and more aesthetically pleasing.--Elvey (talk) 21:06, 17 November 2009 (UTC)
Personally, I don't think we should support it anymore than we do now. The amount of energy savings is trivial. Writing a bot to edit templates and flag signatures would be like putting a lemon into an industrial press to squeeze out every drop of juice because your juicer at home misses half a teaspoon. Mr.Z-man 23:03, 1 June 2009 (UTC)
I think it'll more than halve the energy use of the display, and will make it last several times as long.--Elvey (talk) 21:06, 17 November 2009 (UTC)
Yup; researched it. Wild guesstimate: About 150 million computer monitors are sold per year. Assume 5 year life. Wikipedia daily reach is 13% of web users (per Alexa). On average, the 750MM monitors display a wikipedia page 0.5% of the time. Ok, so in several years, let's say we have 500MM nice OLED monitors using light-on-dark. 500 million * 0.5% * 10 watts saved by using light-on-dark. That's 25 megawatts, which is 5x the average output of the largest solar photovoltaic plant in the USA, which cost $150 million to construct. That's trivial? I think it's worth several hours of programmer time, even if I'm overestimating the impact by a factor of 1000.--Elvey (talk) 03:58, 22 April 2010 (UTC)
You are welcome to make that investment. :D —TheDJ (talk • contribs) 10:39, 22 April 2010 (UTC)
Thank you for taking the time to grant me permission to do; so kind of you. Ahem.--Elvey (talk) 03:25, 23 April 2010 (UTC)
You misunderstand. You can request all that you want, but if no one wants to do such things, you cannot make them, they are volunteers. As such, as in any volunteer process, "if you want something done, do it yourself" it the only way to get it done within any reasonable timeframe. —TheDJ (talk • contribs) 11:05, 23 April 2010 (UTC)
You misunderstand. I'm quite aware of how work gets done in a volunteer system; you assumed otherwise. I think you'd agree that Wikipedia is a collaborative enterprise where some folks concentrate on adding or editing or deleting content, others on improving MediaWiki, others on translating content... What I've done is attempt to convince folks who code to improve MediaWiki that, contrary to what Mr.Z-man has said, making light-on-dark work better is a worthy project to take on. The start-up cost to getting familiar with the relevant MediaWiki APIs and code is in my estimation several times greater than the cost to fix this problem for someone experienced in coding MediaWiki. --Elvey (talk) 14:42, 23 April 2010 (UTC)

restore GeSHi borders?

Starting the inevitable discussion about whether GeSHi borders should be reinstated, per Wikipedia:Village_pump_(technical)#GeSHi_update. Here is my suggestion if so: 

div.mw-geshi {padding: 1em; margin:1em 0; border: 1px dashed #2f6fab;}

Note that this probably shouldn't be added to MediaWiki:Common.css, as most skins have different borders: 

 Pre borders:
monobook: border: 1px dashed #2f6fab;
chick: border: 1px dashed #2f6fab;
modern: border: solid 1px #3c78b5;
simple: border: solid 1px black;
standard: none
cologneblue: none
myskin: none
nostalgia: none

--Splarka (rant) 07:53, 24 June 2009 (UTC)

Note, possible alternate all-skin inclusive solution in MediaWiki:Common.css or MediaWiki:Geshi.css could be:
body.skin-monobook div.mw-geshi {
	padding: 1em;
	border: 1px dashed #2f6fab;
	color: black;
	background-color: #f9f9f9;
	line-height: 1.1em;
}

body.skin-modern div.mw-geshi {
	border: solid 1px #3c78b5;
	padding: 0.4em;
	background-color: #f0f0f0;
}

body.skin-simple div.mw-geshi {
  margin: 2em;
  border: solid 1px black;
}

body.skin-chick div.mw-geshi {
    padding: 1em;
    border: 1px dashed #2f6fab;
    color: Black;
    background-color: #f9f9f9;
    line-height: 1.1em;
}

body.skin-vector div.mw-geshi {
	padding: 1em;
	border: 1px dashed #2f6fab;
	color: black;
	background-color: #f9f9f9;
	line-height: 1.1em;
}
--Splarka (rant) 10:55, 24 June 2009 (UTC)

((sudo))

Uncontroversial change that restores previous behavior. Please add to MediaWiki:Geshi.css. Thanks! --MZMcBride (talk) 02:42, 26 June 2009 (UTC)

 Done. Ruslik_Zero 19:23, 30 June 2009 (UTC)

Duplication of .infobox class code

Comparing the CSS code of the Monobook.css and the Common.css, I found that the class infobox code is repeated. But they're different:

Common vs Monobook
Common Monobook 
.infobox {
    border: 1px solid #aaa;
    background-color: #f9f9f9;
    color: black;
    margin: 0.5em 0 0.5em 1em;
    padding: 0.2em;
    float: right;
    clear: right;
}
.infobox td,
.infobox th {
    vertical-align: top;
}
.infobox caption {
    font-size: larger;
}

.infobox {
    border: 1px solid #aaa;
    background-color: #f9f9f9;
    color: black;
}

.infobox.bordered {
    border-collapse: collapse;
}
.infobox.bordered td,
.infobox.bordered th {
    border: 1px solid #aaa;
}
.infobox.bordered .borderless td,
.infobox.bordered .borderless th {
    border: 0;
}

.infobox.bordered td,
.infobox.bordered th {
    border: 1px solid #aaa;
}

.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
    border: 0;
    border-top: 1px solid #aaa;
    border-right: 1px solid #aaa;
}
 
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
    border: 0;
    border-right: 1px solid #aaa;
}

/* Styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
    border-top: 1px solid #aaa;
    border-right: 1px solid #aaa;
}
 
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
    border-right: 1px solid #aaa;
}

why is it repeated? Locos epraix ~ Beastepraix 15:24, 24 June 2009 (UTC)

(I slightly changed your table to make it a little easier to read, at least for me.) Good point. I'd suggest to just drop the rules here. —Ms2ger (talk) 16:22, 24 June 2009 (UTC)
Yes, there is no point of point of having the two CSS defined, should it be deleted here? Locos epraix ~ Beastepraix 16:36, 24 June 2009 (UTC)

I have removed it. --- RockMFR 15:47, 28 June 2009 (UTC)

Fix for Monobook small font on IE6/9x

Sample shot

Wikipedia on IE6/9x looks for me like the shot to the right (apparently others see it too: see here). The problem is with the font IE6 selects for "sans-serif". The expected one is Arial, but for some reason it doesn't pick it. I suggest an IE6 (or <7) body font-family override from "sans-serif" (main.css) to "Arial, sans-serif" (IE6/IE<7 fixes CSS). I don't see any negative effects this could have besides fixing the problem whenever it happens. Any thoughts? ¤ ehudshapira 23:23, 29 August 2009 (UTC)

It looks like your default font for sans-serif is set to something weird. We generally don't set the font family-name in order to allow for users to use whatever is their browser default. — RockMFR 23:29, 29 August 2009 (UTC)
I don't think there's a way to select fonts for generic families in IE6. ¤ ehudshapira 23:42, 29 August 2009 (UTC)
It looks like Microsoft Sans Serif, Tools > Internet Options > General (tab) > Fonts... > Web page font: should allow you to set the font to your preferred default. Also, you might want to look at the accessibility options to see if something like "Ignore font style specified on Web pages" is checked. — Dispenser 05:04, 30 August 2009 (UTC)
The font setting there is only for pages with no font specified at all (the dialog state so, as well). In my case the font for Latin languages is set to Times New Roman (the factory setting). The accessibility options are all unchecked. The inability to select fonts in IE6 is apparently known, with various discussions on the web. ¤ ehudshapira 16:01, 30 August 2009 (UTC)
Here's one adverse side-effect: specifying fonts in the stylesheet blocks the ability to select your own font in the browser. (e.g. don't remember where it is in IE, but there is a similar option for Firefox in Edit → Preferences → Content → Fonts & Colors) If put to the vote, I would strongly disagree with the change. Also, IEs4Linux defaults to the “smallest” font size for some reason, so going View → Text Size → Medium fixes a lot of font issues for me. — Jeremy 10:38, 1 September 2009 (UTC)
Yes, this concern was mentioned, and I agree it makes sense for browsers that allow you to configure the generic fonts. But again, IE6 is not one of them. There is no way to choose fonts besides the default font for cases where no font is specified at all. From what I gather, for generic families, it picks a font automatically and sticks to it. There may be some ways to trigger a "repick", but nothing predictable or accessible. ¤ ehudshapira 18:04, 1 September 2009 (UTC)
----

So, what about the above? All the objections were assuming IE6 has user-selectable fonts, which isn't the case. My suggestion would either make no difference when the browser uses the expected font, or restore the normal behavior when it picked a random bad font. And it can be limited to older versions. ¤ ehudshapira 15:34, 5 October 2009 (UTC)

There are ways to force IE to use a different font. One way is to uninstall and reinstall whatever font currently the default. I don't think we should be including a font declaration just because a single user has a problem with their IE setup. — RockMFR 21:59, 5 October 2009 (UTC)
Can you logically explain what is "bad" in setting a specific font for a specific version subset of a specific browser that doesn't have any GUI or registry mechanisms to select fonts to the font that would be selected on a fresh OS install and would stay that way on 99% of all computers and when it doesn't it's because the browser's blundered?
Do you suppose there are more users who've found a secret way to select default fonts and set their IE6's sans-serif to something other than Arial than those who are stuck with a bad font? ¤ ehudshapira 02:33, 13 November 2009 (UTC)
I've pinpointed the font, it's "Abadi MT Condensed Light" which is either comes with the OS (same file date/time as OS files) or with Office. And IE doesn't seem to store the used font anywhere, removing or installing the font causes IE to change the page font immediately. It looks like the font selection logic happens on startup and on system font change events. ¤ ehudshapira 22:45, 16 November 2009 (UTC)

Technical question

On the main page, what were the settings used in order to have the green column the same height as the blue column, regardless the length of the text inside them? --Alex:D (talk) 17:25, 15 September 2009 (UTC)

A table, with 2 cells to create 2 columns with different colored background. You can use Firebug or Webkit's Inspector to easily see things like this. —TheDJ (talk • contribs) 16:40, 17 November 2009 (UTC)
More