MediaWiki talk:Monobook.css

From Wikipedia, the free encyclopedia

This interface message is documented on its manual page.
The page forms part of the MediaWiki interface, and can only be edited by administrators. To request a change to the page, add {{editprotected}} to this page, followed by a description of your request.
Notice

For the "Monobook" skin, Wikipedia uses the stylesheet http://en.wikipedia.org/skins-1.5/monobook/main.css . The page here overwrites parts of that. Individual users can customize the skin further for themselves, see Help:User style.

Code common to all skins, and not specific to Monobook, was moved to MediaWiki:Common.css. If you want to propose a change to the sitewide CSS that is not specific to a particular skin, please do so at MediaWiki talk:Common.css rather than here.

All the stylesheets are documented at the catalogue of CSS classes. Please add any new classes into that catalogue.
Archive
Archives
  1. June 2004 - October 2005
  2. June 2005 - December 2005
  3. July 2005 - April 2006
  4. Archive 4
About archives • Edit this box

Contents

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Light BG fix

{{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}
  • Please remove the following, which will be already covered:
/* Give transparent background to table on confirm deletion page */
form#deleteconfirm table {
    background-color:transparent;
}
  • 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.
    • N 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*/.

—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.13alpha (r36195) 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;
}
Y 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)

[edit] Light blue background

darker non-main background

non-main background

mainspace-background

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.Chris_huhtalk 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. Chris_huhtalk 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_huhtalk 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.Chris_huhtalk 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)

[edit] 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 infromation 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)