MediaWiki talk:Monobook.css/Archive 5

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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. C hris_huh^talk 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}}

"LIGHT BLUE SECTION" needs to be fixed, because tables are defined to have a white background, and this doesn't look good when everything else is blue. This happens on Move page, Protect page, and also recently tables were added to enhanced RC/Watchlist. Please add the following:

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

- Done Happy‑melon 22:04, 20 March 2008 (UTC)
Please remove the following, which will be already covered:

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

- Done Happy‑melon 22:04, 20 March 2008 (UTC)
Please shorten the code: 3 2 rules with background-color:#F8FCFF; should be combined into one, 2 rules with background-color:white; should be combined into one.
- Not done I don't know enough CSS to make such a change reliably. If you can give me a "replace X with Y" I'll be happy to do it. Happy‑melon 22:04, 20 March 2008 (UTC)
In the comment please fix the obvious typo "non-namespace" (should be "non-main-namespace"), or better shorten the whole comment into something like /*Light blue background on all non-article pages; need 32bit color to see difference*/.
- Done Happy‑melon 22:04, 20 March 2008 (UTC)

—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.2 (ce9d259) 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)

Convert to white. It tends to make templates look a bit funny when they get transcluded - the difference isn't enough for anyone to notice just by flipping between pages, but it is enough to make backgrounds look funny when it's used in different spaces. Hersfold ^(t/a/c) 04:11, 25 March 2008 (UTC)
By the way, for anyone who has no idea what we're talking about (which I expect is many of you): This: is non-mainspace background, and this: is mainspace background (and side by side so you can see better: non-main main) Hersfold ^(t/a/c) 04:15, 25 March 2008 (UTC)
Keep blue It may not be noticable, but I do feel the distinction should be made... make it slightly darker perhaps? Anyway, This is probably better asked in the Village Pump. — Edokter • Talk • 11:29, 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)

Keep blue I've taken the liberty of changing the wording of the straw poll, and refactoring the comments, as I was initially extremely confused as to what we were commenting in "opposition" or "support" to! Although the difference is subtle, I am constantly aware of how much more... boring... commons and meta look, just because they don't have the blue background. Happy‑melon 18:16, 25 March 2008 (UTC)
Comment - I realize that although I instinctively appreciate the difference in colour, there is regardless little reason for such a bias; we've had this difference for a while and those who appreciate the status quo may wish the distinction. As it's easy to simply duplicate the colour-altering code in one's monobook.css, I cannot offer substantive opposition to such a change (newbies will likely not appreciate or be frustrated by such a subtle difference, and newbies are what I value interface changes against); nevertheless mightn't there be a good reason that the colour change was implemented in the first place? Nihiltres^{t.l} 18:18, 25 March 2008 (UTC)
Convert to white. I've had mine set that way for years, and I think the blue is confusing, particularly for new users. Ral315 (talk) 19:44, 25 March 2008 (UTC)
I can see where a distinction might be useful... but as mentioned, it causes some odd problems when people expect a white background and don't quite get one. Currently the difference is so subtle it takes most people months at least to notice it (or that it's namespace-based), I think. Making the difference more pronounced could potentially mangle quite a few existing pages (mainly userpages)... which I suppose brings up the question of whether a "content vs. talk" distinction might be more useful than the current "mainspace vs. everything else" approach. – Luna Santin (talk) 21:06, 25 March 2008 (UTC)
Comment - I cannot see any difference in the two sample colors above, and I never knew or saw that there was any difference between namespaces. I'm running Safari 2 on Mac OS X. I wonder if it is a Safari thing or if there are other browsers that don't show a difference. Before you make a change it might be good to try to find out how many users have ever seen the two colors. Sbowers3 (talk) 23:47, 25 March 2008 (UTC)
As far as I know, the difference is visible only with 32bit color setting on your video card, but not with 16bit. I also suspect that LCD monitors owners are less likely to see the difference. —AlexSm 23:55, 25 March 2008 (UTC)
24-bit will do fine... 16-bit is still visible as well, but you won't find any user still using 16-bit color. If the difference is unnoticable, it is usually because of a badly adjusted monitor. — Edokter • Talk • 00:12, 26 March 2008 (UTC)
I added two boxes above that are a bit larger and should make the comparison easier --TheDJ (talk • contribs) 00:29, 26 March 2008 (UTC)
32-bit LCD. Can't see any difference even in large boxes. I would have thought that LCDs were better than old-fashioned CRTs re colors. Sbowers3 (talk) 00:39, 26 March 2008 (UTC)
Actually, most (older) LCDs have limited color range, using dithering to compesate. In that respect, nothing beats a good old fashioned CRT. — Edokter • Talk • 13:42, 26 March 2008 (UTC)
This was a real problem for my tool as I use a high quality Trinitron and ended up picking up colors that were too light (based on #f7f7f7 of .wikitable). I ended up darking it after see on many LCD that the colors were indistinguishable from white. Since the colors are used as primary indicators. If we do change the color I would suggest changing the border color to gold like on other languages. — Dispenser 05:16, 27 March 2008 (UTC)
~~Convert to white~~ See below - I think the light blue makes the category pages mess up (ie any pages with a category tree on) as they have a white background. Perhaps some pages could be a different colour (like talk and mediawiki) but I think mainspace, image and categories should be white, as they are accessed by non-contributors; but the colour would really need to be more noticeable.C hris_huh^talk 00:18, 26 March 2008 (UTC)
Surely there are ways we can fix such issues elsewhere. Just means that some things are making assumptions about background colors that they should not make. --TheDJ (talk • contribs) 00:29, 26 March 2008 (UTC)
I suppose, but i still don't see why the image and category pages should be a different background. I think it would make more sense to split the site into two sections (not literally of course) - the encyclopaedia itself (mainspace, image, categories, portal [maybe?]), and then the other for editing issues and help (talk pages, Wikipedia pages, Mediawiki pages, special pages, etc). Then the enc side would be white bg, and the editing side would be pale blue (or something). Or maybe just a different colour for talk pages. C hris_huh^talk 00:45, 26 March 2008 (UTC)
Having the different colours has certainly prompted us to spot a lot of places where tables aren't transparent when they should be; a lot of fixes to MediaWiki have come out of this! Happy‑melon 13:03, 26 March 2008 (UTC)
Increase difference. One of the reasons I use Classic rather than Monobook is the strong difference between the white of mainspace and the yellow used everywhere else. --Carnildo (talk) 18:57, 26 March 2008 (UTC)
Wonderful: seems there's quite a lot of support for a change, but little agreement as to what that change should be. – Luna Santin (talk) 17:30, 27 March 2008 (UTC)
- If a change is made, what code would need to be added to one's monobook.css to retain the current formatting? And please can we ensure that any changes made here can be overruled by such user preferences? I know the system is designed such that that behaviour is default in most situations, but I'm sure many more people than you expect would notice if it was changed. Happy‑melon 17:45, 3 April 2008 (UTC)
  - Making the assumption that the change would be to make every namespace white, all one would have to do, pretty much, would be to copy the code currently here into one's personal monobook.css, which overrides this one. It would also be trivial to create a Gadget to apply it. I don't mind either way (I'll apply it, or something like it, for myself if it's changed, but I need not enforce my personal distinctions upon others). Nihiltres^{t.l} 21:29, 3 April 2008 (UTC)
Keep status quo (light blue for non-mainspace). The difference is noticeable and helpful, and has occasionally kept me from making (or at least thinking about making) an incorrect edit. --MCB (talk) 22:15, 3 April 2008 (UTC)
As with Carnildo, I'd prefer to see the difference made clearer. Christopher Parham (talk) 23:19, 3 April 2008 (UTC)
- I've added a color above that is a bit darker. — Edokter • Talk • 23:53, 3 April 2008 (UTC)
Change namespaces - I've changed my mind from changing everything to white (see above). I think a difference may be useful but it needs to be more obvious (like the new blue) but i still think that it shouldn't simply be mainspace vs everything else. I think mainspace, image, and category should be white (as they are more publicly useful), and then all talk pages, user, mediawiki, wikipedia, special etc should be blue as that more for editors (i'm still not sure about portal though). Chris_huh^talk 00:25, 4 April 2008 (UTC)
- I agree that the difference should be between pages that are user facing: mainspace, categories, templates, image pages, and portals, and pages that are otherwise, i.e. everything else. Christopher Parham (talk) 04:07, 5 April 2008 (UTC)
  - I'm not sure I would count some of those namespaces as "user-facing". Anyone who visits a template page has either typed in a direct link, or gone via page --> EditThisPage --> TemplatesOnPage --> Template, neither of which is going to be a common "reader" action. I'd say that the advantages of being able to see where a template is not using transparent backgrounds when it should are most significant - if a template is intended to be transcluded into project- or user-space, there should be consistency there. I'd also argue that image pages are only barely user-facing - anyone who wants to check the copyright status of an image is not a lay-user. I'd say that "user facing" incorporates the mainspace, Category: and Portal:, and probably Help: as well. Happy‑melon 15:02, 6 April 2008 (UTC)
  - I don't think template pages are very user relevant either, the idea of a template is to use it on another page. But i would argue that image pages are user related, as people go there to get a bigger picture of the thumbnail version available in the article, and will sometimes have extra text about the image. Also i find that i go to image pages mostly to see when it was taken, and maybe where and to see if there is more info available, rather than to check copyright status. As for Help, most people going to the Help pages will be editors (or soon-to-be editors) looking for help, rather than readers. I have also come round to the fact that portal should be included too, since its there for readers.C hris_huh^talk 15:13, 6 April 2008 (UTC)
Darker blue. --Random832 (contribs) 23:43, 4 April 2008 (UTC)
Keep as is. Being able to notice at a glance if I'm on ns-0 or not is one of the main reasons I still prefer to use a CRT monitor. White should be kept for ns-0 only; all other namespaces are special in some way. As for the colour, the very light blue is much less intrusive than other colours would be. --cesarb (talk) 23:57, 6 April 2008 (UTC)
Comment I had never heard of this difference until I read this vote; even then, I went to an article to check that it was true, and I wasn't sure there even was a difference until I flipped back and forth between this page and an article a few times. While I do like the concept of color-coding so that people know easier what is an article, talk page, wikipedia policy/guideline, non-policy/guideline (eg: essays), etc. I don't think that the current system really does that effectively. TheHYPO (talk) 01:35, 7 April 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)

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)

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

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 $e^{i\pi }+1=0$ would become $e^{i\pi }+1=0$ . 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

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)