MediaWiki talk:Monobook.css

Template:Ilm

For the monobook skin, Wikipedia uses the stylesheet http://en.wikipedia.org/style/monobook/main.css . The page here overwrites parts of that. Individual users can adapt this again for themselves, see m:User styles.

Template:Prettytable

In the Talk page of {{prettytable}} it was suggested to take the discussion about moving that template into sitewide CSS here, but somehow nobody did. Therefore I'm repeating my comment from there:

The current code is

border="2" cellpadding="4" cellspacing="0"
style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"

It is correct that IE does not support 'border-spacing', but it does support 'border-collapse: collapse', which always implies "border-spacing: 0", which is the same as "cellspacing=0". It also supports 'padding' for 'td' and 'th' correctly, which is what "cellpadding=4" does. Even that contradicting "border=2" and "border: 1px #aaa solid" is handled the same as in Firefox. Therefore I really cannot see any reason not to move this into the stylesheets (there are more skins than Monobook). Even if in IE some spacing was one or two pixels off or the border color a little darker—it did not matter! Server resources are much more valuable than such a minor glitch. So my proposal is:

table.pretty {
    margin: 1em 1em 1em 0;
    border-collapse: collapse; 
    padding: 0;
    background: #f9f9f9; color: #000;
/*  font-size: 95%;*/
}
table.pretty th,
table.pretty td {
    margin: 0;
    border: 1px #aaa solid;
    padding: 4px;
}

And while we are at it, add something like this, that IE really does not support:

table.pretty th[scope="col"], /* column header */
table.pretty>tbody>tr:first-child>th,
table.pretty th[scope="row"], /* row header */
table.pretty>tbody>tr>th:first-child {
    background-color: #F00;
}
table.pretty th[scope="row"], /* row header */
table.pretty>tbody>tr>th:first-child {
    text-align: left;
}

table.pretty>tbody>tr:hover>td,
table.pretty>tbody>tr>td:hover {/* or '*' instead of 'td' */
    background-color: #8A5;
}

Note that I do not like all the style choices made in this template, especially not the reduced font size. The actual color codes should be skin dependent. Furthermore I doubt that a class is at all required, because we could just make all tables look nice instead (I already did in my stylesheet, but I'm using Standard not Monobook). Christoph Päper 12:16, 23 Jun 2005 (UTC)

"text-align: justify;"

It seems to me that someone is adding and removing "text-align: justify;" in the current stylesheet. It causes the Unicoded texts, especially Tamil to flip in Firefox. See, this bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=270012). So, please don't "justify" text-align. Thanks. --Rrjanbiah 07:53, 5 Dec 2004 (UTC)

This is actually a bug in MediaWiki, where it sometimes sends you the CSS (http://en.wikipedia.org/w/wiki.phtml?title=-&action=raw&smaxage=0&gen=css) for other people's Special:Preferences, instead of your own. If it annoys you do a full reload (ctrl-f5) until it's fixed. Goplat 16:52, 5 Dec 2004 (UTC)

This should have been fixed some while ago, please confirm. --Brion 07:20, Jan 12, 2005 (UTC)

Updating the cache

I make changes to my monobook.css, but they won't show up (I suppose they will someday). I even load the css in my browser window and shift- alt- command-refresh a dozen times—no luck. Sure is a pain to trouble-shoot CSS changes this way. Is there a trick, or just patience required? —Michael Z. 00:01, 2005 Jan 16 (UTC)

Invalid style sheets

Both /skins/monobook/main.css and monobook.css are currently invalid. I've been experiencing some very annoying styling goofiness in Safari/Mac lately. Can someone please remove the invalid declarations and fix the syntax errors? —Michael Z. 2005-01-21 18:03Z

error in TOCs

Please revert this change (http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&diff=next&oldid=10109434) ASAP. It is messing up the display of table of contents. -- Netoholic @ 06:19, 2005 Feb 10 (UTC)

Extra space between paragraphs

I don't like this at all. Fredrik | talk 02:55, 13 Feb 2005 (UTC)

Nor do I —User:Mulad (talk) 02:18, Feb 14, 2005 (UTC)

It looks especially bad for category boxes. Goplat 02:40, 14 Feb 2005 (UTC)

bullet.gif -> bullet.png

The bullet used by lists is bullet.gif. This should be bullet.png, IMHO. It should link to [1] (http://commons.wikimedia.org/upload/7/7a/Bullet.png), so that it is in the control of the Editor. Gerritholl 11:47, 14 Feb 2005 (UTC)

class="plainlinks" fix

Would someone please add this to the file:

    #bodyContent .plainlinks a {padding: 0 !important}

Thanks. – AB CD 03:20, 24 Feb 2005 (UTC)

Another, probably better way would be to add the !important code to the http://en.wikipedia.org/style/monobook/main.css file. – AB CD 03:59, 24 Feb 2005 (UTC)

This was reported (http://bugzilla.wikimedia.org/show_bug.cgi?id=714) twice (http://bugzilla.wikimedia.org/show_bug.cgi?id=1516) but ignored. Goplat 04:32, 24 Feb 2005 (UTC)

Now added to Monobook.css, at least, and seems to be working. Should it be added to other skin stylesheets as well? (And if so, what are their names? I couldn't find a list.... — Catherine\^talk 19:37, 10 Mar 2005 (UTC)

messed up section edit links - CSS or Mozilla issue?

Village pump (technical)#section edit links showing up badly - this may be a problem with the CSS, or it may be a Mozilla/Firefox/etc problem that can still be fixed by changing the CSS. Please have a look. --SPUI (talk) 17:55, 1 Mar 2005 (UTC)

framed image background color

should we change

div.thumb div a img {
    border:1px solid #cccccc;
}

into

div.thumb div a img {
    border:1px solid #cccccc;
    background-color:#ffffff;
}

(I added this to my user css and it works the way I expected.)

to fix this:

Missing image
Currentmirror.png

This should have a white background ~~(or the same background as the page we are currently on?)~~ The image has transparency.

Or maybe we just shouldn't be uploading images with transparent backgrounds? But they look better on pages with colored backgrounds like this:

Missing image
Currentmirror.png
Image:currentmirror.png

- Omegatron 16:39, Mar 21, 2005 (UTC)

Can you make it transparent? My personal CSS makes various namespaces different colours, and the framed areas stand out quite glaringly, although it's actually the area around the frame which is most obvious. --Phil | Talk 17:07, Mar 21, 2005 (UTC)

I think background-color: transparent; would do it. Now that I think of it, it should be white, though. - Omegatron

Nope. This doesn't work when I add it to my user css, presumably because it just shows the color of the gray div underneath it. - Omegatron 17:36, Mar 21, 2005 (UTC)

Also, this is related: Wikipedia_talk:Extended_image_syntax#Multiple_images_in_one_frame - Omegatron 17:27, Mar 21, 2005 (UTC)

See PNG -- the picture has to be saved with binary transparency to display properly in Internet Explorer and some other browsers. — Catherine\^talk 20:34, 21 Mar 2005 (UTC)

It's not about the transparency itself; it's about the background color of the frame, which only shows in the presence of transparency. - Omegatron 17:45, Mar 22, 2005 (UTC)

I'm going to be bold and add it. - Omegatron 17:49, Mar 28, 2005 (UTC)

small :) request

Per discussion at Wikipedia talk:WikiProject Stub sorting#A simple idea to make stub templates look less ugly/obtrusive, could someone with The Power append the following line?

#stub { font-size: smaller; }

—Korath (Talk) 11:55, Apr 14, 2005 (UTC)

Is there a wide consensus for this? I don't like it. - Omegatron 17:14, Apr 15, 2005 (UTC)

Neither do I. – AB CD 18:25, 15 Apr 2005 (UTC)

My first thoughts on seeing the new reduced stub message: "What is going on, they shrunk the stub templates? For what? It looks uglier." I also think it draws attention to the stub messages, instead of making them more ignorable. --cesarb 19:45, 15 Apr 2005 (UTC)

Then I suggest making your displeasure known at the discussion linked above; my part was only to direct the change to place where it could be added (or removed) easily, instead of putting <small> tags in the templates themselves (as had already been started). —Korath (Talk) 20:06, Apr 15, 2005 (UTC)

Somehow the small text is still in place, despite the recent reversion:

This mathematics-related article is a stub. You can help Wikipedia by expanding it (https://academickids.com:443/encyclopedia/index.php?title=MediaWiki_talk:Monobook.css&action=edit).

I wish people would spend less time with stub templates and all of their politics and nonsense and more time fixing stubs... - Omegatron 21:12, Apr 15, 2005 (UTC)

The small text is a caching issue; it should go away if you force a reload of the css link as it appears to your browser (http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400). Stub sorting should hopefully be obsolesced by category math, though that unfortunately seems to be a ways off. —Korath (Talk) 21:49, Apr 15, 2005 (UTC)

indents next to images

I imagine this is just a css problem. See Twisted pair. The bullets along the image are not indented as they would be elsewhere. - Omegatron 17:10, Apr 15, 2005 (UTC)

Actually. Don't see it. I'll show you here:

Bullets indented correctly

Twisting wires decreases interference because:

Bulleted text. The loop area between the wires (which determines the magnetic coupling into the signal) is reduced as much as physically possible.

Indented text. The directions of current generated by a uniform coupled magnetic field is reversed for every twist, cancelling each other out.

Double indented text. The directions of curr

TRIPLE INDENTED TEXT

Triple
- Bulleted
  - Text

Bullets indented wrongly

Missing image
25_pair_color_code_chart.png

25 Pair Color Code Chart

Twisting wires decreases interference because:

Bulleted text. The loop area between the wires (which determines the magnetic coupling into the signal) is reduced as much as physically possible.

Indented text. The directions of current generated by a uniform coupled magnetic field is reversed for every twist, cancelling each other out.

Double indented text. The directions of curr

TRIPLE INDENTED TEXT

Triple
- Bulleted
  - Text

New infobox class

Many infoboxes now use class="toccolours". For good semantics there should really be a class="infobox", initially with the same properties as toccolours. Also seeing as most infoboxes (in fact, everyone I've ever seen) floats right, it would be good to include an .infobox.right class (or similar) which defines properties such as float:right; clear:right; left and bottom margins. If we could come to a site-wide agreement this would save a lot of arguments based around "but it's not a table of contents", and we could easily bring some consistency to Wikipedia's ubiquitous infoboxes. ed g2s • talk 15:41, 16 Apr 2005 (UTC)

Proposed classes:

.infobox { 
   border:1px solid #aaaaaa;
   background-color:#f9f9f9;
   padding:5px;
   font-size: 95%;
   border-collapse: collapse;
}

.infobox.right /* this may have to be .infobox.info_right if the class .right already exists */
{
   float:right;
   clear:right;
   margin:0 0 1em 1em;  /* 1em to the left and below */
}

/* Other possible classes that would be useful, in my experience */

.infobox tr
{
  vertical-align: top;
}

.infobox_image
{
   border:1px solid #aaaaaa;
   padding: 0;
}

ed g2s • talk 15:41, 16 Apr 2005 (UTC)

Stupid question, I know, but why not just make the infobox class itself include the float:right and margins, and have a special form with float:none for those that want it?

James F. (talk) 20:42, 16 Apr 2005 (UTC)

I agree with James, better to default to float:right. -- Netoholic @ 20:05, 2005 Apr 26 (UTC)

We should probably have a class for navigation boxes then too. ed g2s • talk 08:46, 27 Apr 2005 (UTC)

Default to float:right. In the very rare case that this isn't desirable, it can be overridden with a style attribute in the page.

Some other suggestions:

use shortcuts, like #aaa instead of #aaaaaa.
use keywords for font size.
0.5em bottom margin always leaves a line space, but doesn't get too big.
centre images.
keep it simple and minimal.

   .infobox { 
      border:1px solid #999;
      font-size: 95%;
      border-collapse: collapse;
      float:right;
      clear:right;
      margin:0 0 .5em 1em;
   }
   
   .infobox tr th, 
   .infobox tr td {
      vertical-align: top;
   }
   
   .infobox image {
       margin: 0 auto;
   }

Adding the styles to the style sheet also gives us the opportunity to redesign the infobox. I've made up a specific proposal at User:Mzajac/sandbox#AFV infobox. —Michael Z. 2005-04-27 15:11 Z

I have 3 comments/requests - see below:

(1) I think we should consider changing from the gray color to white or something else. For exampe #F9F9F9 becomes white on 256 color machines. Additionally, other customizations such as the debate which sparked this at Template:Infobox pope are attractive, not overly fancy and give Wikipedia a nice fit and polished look.

Not all infoboxes are created equally - I think navigation type infoboxes such as the ones that are used for a series of related articles as a kind of quick link table of contents for related articles such as Template:christianity, Template:Worldmusicbox, Template:USmusic, etc are much more effective that Categories for quick navigation amongst closely related articles. (2) These should probably resemble as close as possible the Table of Contents look and feel since they serve a similar purpose.

However some infoboxes are mearly informational with few wikilinks (see Template:Infobox Game for an example) others like the Infobox pope provide mostly information with rarely used links to location of birth, links to significant dates, etc.(3) I see no reason why these should all conform to a standard box style other than a few guidelines, lines no thicker than x, no more than 2 horizontal lines in the middle of the box, etc. The use of templates allows these formatting characteristics to be standard across related articles without the extra burden of making them standard across the entire project. The community itself will force attractive (no Bold RED on light Orange titles) through concensus rather than programming decree User:Trödel/sig 16:33, 27 Apr 2005 (UTC)

I think for this skin we should stick to the standard colours - when we had a vote on the image thumbnails (see meta), this style was a run-away winner, and for a good reason. ed g2s • talk 18:57, 27 Apr 2005 (UTC)

Actually white is a standard color for a box in the monobook class - which is the color you have criticised at Infobox pope. I still don't understand what your objection is to that template. "it doesn't match toccolours" is not enough - there must be some reason that you want to use toccolours - have you modified your monobook.css file so that it displays in very different colors which you need for some reason. If so the suggestion to have more than one style for different kinds infoboxes (that match the theme) is a good compromise. Please help me to understand your concern User:Trödel/sig 20:19, 27 Apr 2005 (UTC)

Ed's not interested in dialogue, only in convincing everyone that everything must be homogenous and conforming, and that there is no wiggle room for varying the style of the presentation to any degree, regardless on how the style clashes with the coloring of the presented information. There is nothing that mandates the use of toccolours, and by forcing it into the infoboxes he's stifling community involvement. Carry on in creating the infobox you feel you need to make and don't be inhibited by a non-existent style mandate that not everyone finds appealing. - UtherSRG 18:59, Apr 28, 2005 (UTC)

css specification of line-height using "em" is bad

Monobook makes frequent use of line-height specifications using the unit "em". While these lengths _are_ font-size-relative, which is good, the computed value, and not the relative value is inherited by child elements, which is bad.

The problem becomes apparent when a child node uses a different font-size. E.g. many boxes on Wikipedia use font-size:80%. However, because the computed value of line-height is inherited, the line-height stays unchanged (i.e. too large) and the style of the box has to manually fix the line-height.

The solution is to use plain number line-heights, i.e. "1.5" instead of "1.5em". That way, the line-height will properly scale when the font-size is changed.

Here's the relevant section from the CSS2 spec: http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height

 Values for this property have the following meanings:
 [...]
 <length>
     The box height is set to this length. Negative values are illegal. 
 <number>
     The computed value of the property is this number multiplied by the
     element's font size. Negative values are illegal. However, the
     number, not the computed value, is inherited.

Crossposted at http://bugzilla.wikimedia.org/show_bug.cgi?id=2013

K. Sperling 00:53, 2005 Apr 29 (UTC)

A request for CSS experts

I have a query at Wikipedia_talk:A_proposal_re_BCE-CE_Debate#Let's implement a preference-based solution today about what is technically possible with CSS. If answered positively, it may help break the deadlock in the interminable BC/BCE debate, so please have a brainstorm about the best solution and comment there! Many thanks. Pcb21| Pete 10:11, 16 May 2005 (UTC)

New class "plainlinksneverexpand"

I have added a new class "plainlinksneverexpand" that behaves like the existing class "plainlinks", but not only suppresses the external link arrow but also URL expansion. Resulted from this discussion at the Village pump (http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=14159244#Assistance_with_printing_stylesheet). See also Template talk:Ref and Template:Ref, where this is used. Does this need to be ported over to other skins (Cologne, Classic)? Lupo 20:36, 24 May 2005 (UTC)

Does this also fix the Template_talk:Ref#Printing_problem., where URLs of references were being printed? (Not necessary because the references are further down in the article) (SEWilco 06:41, 26 May 2005 (UTC))

Yes it does. In fact, that was what prompted me to add this new class. Lupo 07:47, 26 May 2005 (UTC)

Is it possible that recent edits to monobook.css, Template:Tl or Template:Tl broke the working of footnotes? This was pointed out by Raul654 at Wikipedia talk:Featured article candidates#Extremely important problem!. I've crossposted this at the two relevant talk pages as I don't know where to search for the problem. — mark ✎ 17:39, 4 Jun 2005 (UTC) Never mind, it's most probably caused by a Mediawiki bugfix as was pointed out by Cesarb at User talk:Raul654. — mark ✎ 17:54, 4 Jun 2005 (UTC)

The date given there is June 2. The Template:Tl and Template:Tl behavior has been discussed since June 1. Wikipedia_talk:Footnote3#template:note_now_broken (SEWilco 03:37, 5 Jun 2005 (UTC))

Can't June 2 equal June 1 depending on the relative timezones? Now if you can find a complaint before June 1, or show the time of the problem is before the time of the fix, things would become more interesting. --cesarb 20:24, 11 Jun 2005 (UTC)

forcing underlined links?

Does anyone know why we override people's browser settings to underline links? I can't find the original discussion on this - although there is some stuff in the archives from people saying they would prefer us not to have this in the style sheet. We have had an email to the foundation pointing out that this can be an accessibility issue for some types of vision problems. Of course, forcing people to view without underline would also cause accessibility problems for some, so surely we should leave this to browser settings. I know we have preferences settings for this, but that's not a good solution for our large number of non-logged in readers. -- sannse (talk) 20:06, 11 Jun 2005 (UTC)

The preferences setting doesn't actually work for the default monobook skin. Users need to customise their monobook.css page to remove the underlines. The choice might have had something to do with the Link style vote. I'd rather it were left to browser defaults if that's possible, but I don't know if that can be changed using this page. Angela . 21:53, Jun 11, 2005 (UTC)

I believe (emphasis believe) that removing the very first line of the style sheet would change this. I would, however, be wary of doing this without a vote first. Removing any explicit instruction should make this work. smoddy 22:11, 11 Jun 2005 (UTC)

How come? I use the Monobook skin, and the preference to remove the underlines does work for me... I don't even have a custom monobook.css. --cesarb 22:58, 11 Jun 2005 (UTC)

The override (to no underlines) does work for me on Firefox and Mozilla, but not on IE. On Firefox and Mozilla, the preference works to turn underlines back on. So it could be a browser problem... the CSS validates fine (http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMediaWiki%3AMonobook.css&warning=1&profile=css2&usermedium=all) however, so it's probably an IE quirks thing. --bainer (talk) 09:23, 12 Jun 2005 (UTC)

Retrieved from "https://academickids.com:443/encyclopedia/index.php/MediaWiki_talk:Monobook.css"