MediaWiki talk:Monobook.css/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

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; 
    background: #f9f9f9; color: #000;
/*  font-size: 95%;*/
}
table.pretty th,
table.pretty td {
    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)

So is there a reason that there have some changes been made to MediaWiki:Monobook.css since I wrote this, but I haven't even gotten a reply (neither positive nor negative)? Shall we go on using that ugly compromise that is Template:Prettytable? Christoph Päper 28 June 2005 15:39 (UTC)

I have not tested your .pretty-code, but I like the initiative. If it works in the major browsers, I cannot see why we shouldn't include it in the stylesheet(s). The Template:Prettytable is temporary and usable, but hard on the servers. -Fred Bradstadt 09:59, July 21, 2005 (UTC)

Er... guys, I didn't know about this... and I just added some tags to MediaWiki:Common.css... which I have applied to Microsoft Jet. - Ta bu shi da yu 10:09, 21 July 2005 (UTC)

Right, I just noticed that as well :-) I'm im favor of changing the css on Common.css with the css listed above, since it has relative margins and better colors. Though, I like the idea of <th> having a background color, for example #efefef. What do you think?

Another argument in User:Crissov's edit above is that we could change the look of tables in general, so they would all look "pretty". Does anyone here know to which extend that would break the style for the entire page? -Fred Bradstadt 10:33, July 21, 2005 (UTC)

Whatever you do, don't use the word "pretty" in the class name! A class name should describe the function on the element, not the current appearance, which is likely to change. See what the W3C has to say on the matter: http://www.w3.org/QA/Tips/goodclassnames . ed g2s • talk 11:13, 21 July 2005 (UTC)

I agree, but I cannot come up with a better name than "pretty", maybe because I cannot describe which tables should be "pretty" and which should not. The ones that should not be "pretty" are fx infobox, taxobox and other tables that ought to have their own css class definitions. So maybe the "prettytable" thing should really apply for tables in general? But, as mentioned above, I do not know the exact consequences of changing the css for tables in general... -Fred Bradstadt 11:28, July 21, 2005 (UTC)

Finally I got attention! Maybe I should have added this to the bottom of the page like I usually do.

I advocate good class names myself, but ‘pretty’ is a border case IMO. Name it whatever you want, though, as long as people can remember it and associate with the correct meaning, which currently is just prettyfying. This argument would of course be nil, if all tables were changed.

Note that the second part of my code, that is not intended to work in IE, is not perfect. If Wikipedia really used XHTML—currently it's just tagsoup labeled as XHTML, which is bad—the selectors with ‘tbody’ would not work; solution: duplicate and remove “tbody>” once. The header background color part is of course just an example, often just selecting ‘th’ would be enough (and nobody uses ‘scope’ on WP anyway). Christoph Päper 11:53, 21 July 2005 (UTC)

What about default table, standard table or skinned table? I'm sure that between us we can do better than "pretty". ed g2s • talk 12:28, 21 July 2005 (UTC)

“Default” or “standard” should be just ‘table’, not ‘table.foo’. “Skinned” implies that it's different in each Skin, i.e. it wouldn't belong into common.css. Christoph Päper 13:36, 21 July 2005 (UTC)

Hey guys, I think this is an important initiative - let's not leave it stranded because we cannot agree on a class name! Are there any problems in changing the general table design to the prettytable css? -Fred Bradstadt 11:46, July 24, 2005 (UTC)

I agree that if the intention is for this to be the default table styling then it shouldn't have classname at all, but should only apply to all tables inside an article (i.e. replace table.pretty { ... } with #content table { ... }). I can't see any other problems with implementing it. ed g2s • talk 12:59, 24 July 2005 (UTC)

Please see my suggestions on MediaWiki talk:Common.css#Proposal for CSS for tables. -Fred Bradstadt 16:15, August 20, 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. 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 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 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], so that it is in the control of the Editor. Gerritholl 11:47, 14 Feb 2005 (UTC)

Things like bullets and the Wikipedia logo should not be in control of the editor.  :-) - Omegatron 20:13, July 9, 2005 (UTC)

class="plainlinks" fix

Would someone please add this to the file:

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

Thanks. – ABCD 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. – ABCD 03:59, 24 Feb 2005 (UTC)

This was reported twice 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:

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:

- 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)

And no one has complained! - Omegatron 20:13, July 9, 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. – ABCD 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:

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. 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

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

Unfortunately there is no practical way to fix it. The problem is that the margins and padding for the text items are all less than the width of the image. If the text was wrapped in a <div> with a style of margin-left:125px (125 px because the image is 100px wide + padding), you would see normal (desired) formatting. But because there is normally no way to determine how much text will be affected (it depends on an individual's browser settings), it is just not practical to do that. Instead you will just need to avoid left-floating an image with a list. Float it to the right instead. (I did add it to the article Twisted pair as an example of what it would look like.) —Mike 02:10, July 21, 2005 (UTC)

I don't see any problems in Safari or Firefox, but the bullets to the right of the image disappear in MSIE/Windows. Maybe they'll fix it in MSIE 7. —Michael Z. 2006-02-1 20:42 Z

The problem is in Firefox. The indented text should be indented. — Omegatron 23:45, 5 February 2006 (UTC)

Oops; I wasn't paying close enough attention. In Firefox (1.5.0.1) the bullets indent, but the definitions don't. In Safari none of them indent. Likewise in MSIE, plus the bullets disappear. Something to do with collapsing margins, I guess. —Michael Z. 2006-02-06 05:47 Z

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 Trödel|talk 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 Trödel|talk 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. 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, {{note}} or {{ref}} 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 {{note}} and {{ref}} 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 however, so it's probably an IE quirks thing. --bainer (talk) 09:23, 12 Jun 2005 (UTC)

The line "forcing" underlining was apparently removed today by ABCD. Unfortunately, that broke underlining entirely for me, on Firefox 1.0.6. (I have "Underline Links" set in my browser preferences, but they no longer appear at all, when using the Monobook skin.) I left ABCD a note on his/her talk page, but unless this was discussed somewhere else, it seems unwise if it breaks things. I would revert it but I do not know how, since it comes from Mediawiki and is not a local page. I don't know enough about CSS to know why removing the line forces no underlining instead of letting it be determined by browser prefs. MCB 23:34, 14 October 2005 (UTC)

Request

Wikipedia:WikiProject Spoken Wikipedia would like to put a link to spoken articles to the right of the page heading. For this we will require the following piece of css added:

h1#spoken {
  display: block !important;
  border-bottom-style: none;
  float: right;
  font-size: 150%;
  position: absolute;
  right: 2%;
  top: .25em;
}

A demonstration of what this will look like is Wikipedia_talk:WikiProject_Spoken_Wikipedia#Link_at_top_of_article.3F here. Ta, Joe D (t) 13:54, 26 Jun 2005 (UTC)

This code urgently needs to be corrected to:

#spoken {
  display: block !important;
  border-bottom-style: none;
  float: right;
  font-size: 150%;
  position: absolute;
  right: 2%;
  top: 0.6em;
}

...in order to deal with a problem in MediaWiki 1.5. — Chameleon 28 June 2005 12:05 (UTC)

I've changed the distance from the top from 0.25 to 0.6em which works better for me in Opera and IE when using div, I haven't checked in firefox though. Joe D (t) 28 June 2005 12:23 (UTC)

OK, that code got screwed up by the site notice. I think that the following code is definitive and should always work:

#bodyContent .plainlinksneverexpand a {
   background: none !important;
   padding: 0 !important
}

#bodyContent {
    position: relative;
}

#spoken {
  position: absolute;
  float: right;
  text-align: right;
  font-size: 90%;
  right: 0;
  z-index: 1;
  background: none;
  border-bottom-style: none;
  top: -2.2em;
}

— Chameleon 30 June 2005 12:05 (UTC)

This bit screws up Z-ordering in Internet Explorer, causing bugzilla:2641 (header lines displaying over floated infoboxes), for example on Owl (comics), see screenshot:

#bodyContent {
    position: relative;
}

I'd recommend removing it. --Brion July 1, 2005 03:57 (UTC)

I agree with Brion. This change causes problems with header lines and infoboxes in literally hundreds of pages in IE. —Lowellian (talk) July 1, 2005 08:47 (UTC)

It also causes problems in the country portals. —Lowellian (talk) July 1, 2005 22:15 (UTC)

Note: I have removed the line that Brion indicated. —Lowellian (talk) July 1, 2005 08:51 (UTC)

OK, but that breaks the display of pages with {{Spoken Wikipedia}}. What are you going to do about that? — Chameleon 2 July 2005 09:38 (UTC)

Since the fix for Spoken Wikipedia was what started the problems, you need to find a fix for Spoken Wikipedia that doesn't cause problems with other things. —Lowellian (talk) July 6, 2005 22:39 (UTC)

Lowellian, Brian: Maybe you guys have something weird in your CSS or something? Because I never saw this "header lines" bug in the fisrt place. BLANKFAZE | (что??) 4 July 2005 14:02 (UTC)

I don't have anything weird in my CSS. And the problem wasn't just a "header lines" bug; it caused problems in country portals which several other people complained about. —Lowellian (talk) July 6, 2005 22:43 (UTC)

Yo! Can all you guys just stop messing around with Monobook.css? It was working fine until about four days ago. Now things have been really getting screwy all over WP (like header lines shooting straight through infobox templates), which is why I just visited this talk page to figure out what's going on.

I'm not sure Spoken Wikipedia is really that important (last time I checked, blind Web users use speech readers) but if we really need links to versions spoken by human beings, I don't understand why we can't just put a link in the toolbox or in the page footer. --Coolcaesar 4 July 2005 17:07 (UTC)

Spoken heading bug

Can anyone tell me why the screenshot above is doing this? It's happened on Wikipedia:No personal attacks, and I am running Windows XP, Mozilla Firefox 1.0.4, using default monobook skin. - Ta bu shi da yu 4 July 2005 02:25 (UTC)

Same problem for me (slightly different position; it's exactly below "my contributions" and "log out"). Debian GNU/Linux, Mozilla Firefox 1.0.4, default monobook skin. You probably should ask on MediaWiki talk:Monobook.css, which is where a lot of the previous discussion about this problem is. --cesarb 4 July 2005 02:35 (UTC)

Done. Anyone know of this issue? - Ta bu shi da yu 4 July 2005 02:48 (UTC)

Could it be because the voting notice is shifting the article title and text, but not the spoken article link, down a line? — Dan | Talk 4 July 2005 02:56 (UTC)

No, the css is designed to work around that. It was working fine two days ago but started breaking for me at a time when neither the CSS code or the spoken template had been edited, so I don't know what has set it off. Joe D (t) 4 July 2005 11:17 (UTC)

Man, somebody must have fucked with something. Because this was perfect a few days ago. BLANKFAZE | (что??) 4 July 2005 13:54 (UTC)

• • Update: I found the culprit. The last edit to the MediaWiki page, [2] 08:50, 1 July 2005 / Lowellian / (removing line that causes problems with header lines and infoboxes in IE; see talk)... I reinserted this line into my user CSS and the template box returned to its old position. This line was removed apparently because of a bug above. But I never noticed that bug so I guess I will just keep this line in my CSS. BLANKFAZE | (что??) 4 July 2005 13:57 (UTC)

If you want to see the bug in action, go take a look at Wikipedia:Wikiportal/Brazil or Batman using Internet Explorer with the CSS line I removed still inserted. —Lowellian (talk) July 6, 2005 22:58 (UTC)

Can somebody just revert this back to the version [3] from the 26th? We can use a temporary fix to get around the sitenotice bug, the current css doesn't work at all. Joe D (t) 5 July 2005 15:39 (UTC)

Invalid CSS ("filter" declarations)

Monobook.css won't validate as CSS2 because of the following declarations. Are these MS-specific extensions, or CSS3 properties? If the former, is there any reason not to move them to the MS-specific style sheet? If the latter, why are we using them? —Michael Z. 2005-07-4 21:40 Z

/* Experiment: slightly fade inactive tabs */

#p-cactions a {
   filter: alpha(opacity=90);
}
 
#p-cactions a:hover, #p-cactions .selected a {
   filter: none;
}

filter is an Internet Explorer extension. --cesarb 4 July 2005 23:32 (UTC)

I tracked down the addition. User:Tom- added this experiment in January. Can someone with MSIE/Windows confirm whether this experiment is successful or not? Furthermore, can someone move the code to the appropriate MSIE-specific style sheet(s)?

After six months, I'd like to remove this code from monobook.css so it can validate as CSS2. —Michael Z. 2005-07-5 20:14 Z

Agreed. We certainly should aim for validation over browser-specific extensions. — Trilobite (Talk) 5 July 2005 21:48 (UTC)

Forgot all about this; was just reminded. I've removed the offending CSS. —Michael Z. 2005-09-22 15:24 Z

Template:TOCright

It appears this is a deliberate attempt at bypassing the default style sheet. It is sometimes useful (see List of volcanoes), but these instances are rare. - Ta bu shi da yu 5 July 2005 03:57 (UTC)

Margin for .notice

The class for notices like template:mergeto (.notice) looks like this:

/* Style for "notices" */
.notice {
   text-align: justify;
   margin: 1em 0.5em;
   padding: 0.5em;
}

Would anyone object to my making the horizontal margin 1em, so it doesn't look different from notices that use a colon for formatting? (E.g., template:merge, which is currently protected). —Michael Z. 2005-07-5 19:47 Z

I support this. Changing it to "margin: 1em;" would be better. -- Netoholic @ 5 July 2005 19:57 (UTC)

Done. —Michael Z. 2005-07-5 20:32 Z

Common CSS

I noticed it's common for the different skins to get out of sync (things that should be added to all of them are only added to Monobook.css, until someone else takes notice and updates the others). What would you think about creating a MediaWiki:Common.css and adding the following line to the top of all the skin stylesheets:

@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css&smaxage=2678400";

This way, content styles (like for instance .notice) could be updated in a single location, and the skin-specific stylesheets would need to worry only about the user interface. Since it would be added to the top, the CSS cascade could be used to override the common style, if needed.

--cesarb 9 July 2005 19:16 (UTC)

Since nobody objected, being bold and creating. --cesarb 16:34, 11 July 2005 (UTC)

I have moved all the CSS which was common for the 4 skins I could find (where's MySkin's CSS?) to MediaWiki:Common.css. Now the CSS for the other three skins is empty except for the import of Common.css. I believe there's more to move there (and in fact I moved one of them, #disambig); the other skins seem to have been neglected for a long time. I have checked it all validates and works on Firefox, but I haven't tested on IE. --cesarb 17:18, 11 July 2005 (UTC)

Myskin doesn't have CSS. That's the whole point of it. You supply your own. You can user myskin to make custom skins. BLANKFAZE | (что??) 17:51, 21 July 2005 (UTC)

What the heck happened to redlinks?!

The "new" look is stupid. Please change it back. - Ta bu shi da yu 09:29, 13 July 2005 (UTC)

Did someone change them again? Suddenly I get red question marks, instead of red text/underlines. -- nae'blis _(talk) 19:18, 21 July 2006 (UTC)

commonPrint.css, and Common.css

The following came up on Template talk:Ref:

Can anyone tell me what's happening here? When I print the URL is expanding.... I thought we didn't want to do this. - Ta bu shi da yu 07:42, 15 July 2005 (UTC)

On what page? Note that the last time I looked, it was called plainlinksneverexpand... Lupo 08:45, July 15, 2005 (UTC)

Ok, got it. First, the class of the link has changed from ".urlexpansion" to ".external.autonumber", and second, someone has added the following to our common printing CSS:

#content a.external.text:after, #content a.external.autonumber:after {

/* Expand URLs for printing */

content: " (" attr(href) ") ";

}

Someone should disable this for a.external.autonumber if it's within a SPAN of class ".plainlinksneverexpand". It should be done in commonPrint.css, which I don't know how to edit. Lupo 09:04, July 15, 2005 (UTC)

On another note: why does the import of Common.css have a maxage? Lupo 09:04, July 15, 2005 (UTC)

It has the same maxage as the import of Monobook.css (in fact, I copy-and-pasted the line from the MediaWiki-generated stylesheet). I wanted to avoid any side-effect, so I imported it exactly the same way Monobook.css is imported. --cesarb 21:25, 27 July 2005 (UTC)

Well I'm glad someone understands what went wrong, my CSS skills are little more than font styling... hopefully this gets fixed soon, it's preventing me from making PDFs... Garrett^Talk 02:08, 17 July 2005 (UTC)

This is evidently something we don't have access to. I have raised a bug asking for us to gain access to commonPrint.css so we can sort out these issues. - Ta bu shi da yu 04:18, 18 July 2005 (UTC)

I've fixed this in MediaWiki:Common.css. Lupo 08:28, July 19, 2005 (UTC)

Notice the space between the horizontal rule and the image frame.

borders around thumbs

On main.css, there are the following rules:

div.thumb {
    margin-bottom: 0.5em;
    border-style: solid; border-color: White;
    width: auto;
}
...
div.tright {
    clear: right;
    float: right;
    border-width: 0.5em 0 0.8em 1.4em;
}
div.tleft {
    float: left;
    margin-right:0.5em;
    border-width: 0.5em 1.4em 0.8em 0;
}

Looks to me that borders are being misused, the effect intended is that one of margins. Here, on Monobook.css, you have

#content div.thumb {
    border-color: #F8FCFF;
}
...
.ns-0 * #content div.thumb {
    border-color: white;
}

just to change the color of these borders, to match the page background (and this is more annoying because IE doesn't support transparent borders, and so, we can't use border-color: transparent. Was there a good reason borders where used instead of margins? --Miles 15:33, July 16, 2005 (UTC)

Notice the space between the horizontal rule and the image frame.

Miles, if you will notice I have added an example image and horizontal rule to illustrate the purpose of using a border instead of a margin. ...

---

... The margin will not prevent the horizontal rule from coming in contact with the image frame, but a border which matches the background does. —Mike 07:07, July 21, 2005 (UTC)

Thanks. Now it makes perfect sense. --Miles 03:18, July 30, 2005 (UTC)

It might make perfect sense in this case, but it is a hack, and wreaks havoc with colored background boxes (like are recommended for every portal). Here's what I mean:

Notice the odd-shaped space around the image frame.

And the borders change depending on which side the thumbnail is on.

The thumbnail- on-a-background doesn't look good because of the hacky borders around the thumbnail frame, ostensibly done to make separators look better.

Also, the top and bottom borders are not useful for this hack.

So it's not a no-brainer, obvious hack to do. On one hand, we wreck portal use of thumbnails but on the other, rules don't look great.

I'd thought something like this would work:

hr {
   margin: 0 auto 0 auto;
}
div.tright {
   clear: right;
   float: right;
   margin-left:0.5em;
   border-width: 0 0 0 0;
}
div.tleft {
   float: left;
   margin-right:0.5em;
   border-width: 0 0 0 0;
}

But it doesn't work like it should. It's OK on IE, but bad on Mozilla Firefox. This should be fixable, right?

--FJM 09:59, 8 August 2006 (UTC)

The "rules" that cause the problems (the ones under headings) are actually lower borders, if you look at the CSS code, not rules at all. So fiddling with hr won't do much. —Simetrical (talk • contribs) 19:21, 8 August 2006 (UTC)

Ah, so Mike's h-rule example above isn't actually the whole reason for having these white-borders-as-margins.

<h2>Borders around Thumbs header test</h2> (See http://bugzilla.wikimedia.org/show_bug.cgi?id=6575 for the above weirdness)

I've added an example at the top of this section that shows the wanted behavior. --FJM 09:24, 9 August 2006 (UTC)

Can you not add "border-color: white; border-color: transparent;": won't MSIE stick with white because it doesn't understand transparent, but all other browsers override white with the second border-color declaration? This way it's only slightly broken in the broken browser—so sad, too bad. —Michael Z. 2006-08-08 15:20 Z

If you make the border transparent, you may as well go with margins. The point of using borders instead is to not have them be transparent, so that the pseudo-rules under level 1 and 2 headings don't run into them. —Simetrical (talk • contribs) 19:21, 8 August 2006 (UTC)

OK, it seems that Mike's description of the "border which matches the background" "prevent[s] the horizontal rule from coming in contact with the image frame" isn't a good way to describe what happens. Actually, the opaque border which matches the background actually paints over any elements that are below it. And a float element will only move text out of the way; it doesn't deal with "graphic" elements like h-rules or borders of text boxes (you can see the problem with the dotted "source" box under the section header — the float doesn't reduce the width of that border or of the h2 bottom-border.)

But I do have a solution for my problem. (And yes, it's a hack on a hack.)

Notice the odd-shaped space around the image frame.

The thumbnail- on-a-background looks fine after overriding the "thumb right" style. Perhaps this should be added the /box-header used by most portals? Also, is there a test page for people to compare with before making changes to monobook.css?

--FJM 12:48, 9 August 2006 (UTC)

Redirects on Special:Allpages

I've added a class to all redirects on Special:Allpages called allpagesredirect, please style it somehow (maybe make it grayer). —Ævar Arnfjörð Bjarmason 13:39, 19 July 2005 (UTC)

The change should be made on MediaWiki:Common.css. I tried out this styling, which I'll probably keep:

.allpagesredirect { font-style: italic; margin-left: 1em; }

-- Netoholic @ 14:10, 19 July 2005 (UTC)

Spoken

Can somebody revert the spoken code to:

#spoken {
 display: block !important;
 border-bottom-style: none;
 float: right;
 position: absolute;
 right: 2%;
 top: 0.6em;
}

The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)

Floating images

The div.tleft class used for images that float to the left is missing a clear: left;. This sometimes causes an image to be placed next to another float instead of below it. The div.tright class properly does clear: right;

It should probably go into /skins-1.5/monobook/main.css, but if I'm not mistaken that file is distributed with the mediawiki software and won't change until mediawiki is upgraded to a new version. So putting it into this one would be a good workaround until then. --K. Sperling 20:40, July 28, 2005 (UTC)

Possible CSS problem with floating images

See the edit links on [4]. - Omegatron 19:54, July 29, 2005 (UTC)

I presume (although the diff links have gone now that the page is no longer current) that you are referring to an edit link gone south. This is a common and probably unfixable fault with floating objects in CSS. [[smoddy]] 22:16, 29 July 2005 (UTC)

Bugzilla:4855 is related, though not a solution. — Omegatron 04:40, 8 February 2006 (UTC)

your wiki doen't validate

W3C CSS Validator

Errors URI : http://en.wikipedia.org/wiki/Main_Page Line: -1 unrecognized media screen,projection URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line: 151 Context : #p-cactions a Parse Error - opacity=90) Warnings URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line : 155 property filter does not exist for this profile, but is validated conforming to another profile

Anoniwiki 10:21, 21 August 2005 (UTC)

I wonder which profile supported filter, which is an MS extension with an invalid or at least unspecified value syntax (CSS functions take comma separated parameters, but no assignments with the equals sign). That experiment, which is inappropriate in a production environment anyhow, should of course use opacity: 0.9 as soon as CSS 3: Color advanced to the next status, or one of the color notations with alpha value (e.g. rgba()). Note that that Draft has serious yet unresolved issues. Christoph Päper 19:11, 21 August 2005 (UTC)

I just came here to say the same thing. I don't know how important validating really is, but I think we should either remove the piece of IE-specific code, or make it work in all/most browsers. This, for example, should work in at least Gecko, IE and Safari:

#p-cactions a {
   opacity: 0.9;
   filter: alpha(opacity=90);
}

#p-cactions a:hover, #p-cactions .selected a {
   opacity: 1;
   filter: none;
}

— Sverdrup 16:36, 22 August 2005 (UTC)

I've removed the offending CSS (see #Invalid CSS ("filter" declarations) above). I don't know why media="screen,projection" is poo-pood by the validator; it looks right to me. —Michael Z. 2005-09-22 15:32 Z

Portal namespace

Should the background color of the new Portal namespace be the same light blue it currently is, or should it be changed to white (same as the articles and the Main Page)? Now that it's a separate namespace, it would be very easy to change the color, and it would better match the look of the Main Page. --cesarb 18:02, 28 August 2005 (UTC)

Add topical navigation menu(s) to every Wikipedia page

This is a proposal to address the difficulties many users experience when they try to thematically navigate Wikipedia after they leave the Main Page: add one (or add one and expand one) topical navigation menu to Mediawiki:Monobook.css. The elements would be those contained in Template:Categorybrowsebar located on the Main Page. In this template, the first line focuses on the main categories while the second line focuses on browse options. Adding the elements to this style sheet would allow Wikipedia to have a topical, top-level navigation scheme, based on the primary categorization scheme, that would help users move about logically and quickly from any page. Another benefit of this implementation would be that Template:Categorybrowsebar could be removed from a prominent position on the Main Page and several other high-level pages. — RDF ^talk 17:48, 12 September 2005 (UTC)

p.s. If this is the wrong place to make this proposal, please let me know where I should go. ;-) — RDF ^talk 19:14, 12 September 2005 (UTC)

One menu version

Here's a one-menu version (Template:Categorybrowsebaroneline) that could span across the top of a page.

Culture | Geography | History | Life | Mathematics | Science | Society | Technology | Categories | Portals | Articles | Alpha | More

Here's a script version of that template (complements of pile0nades^{talk | contribs}) developed for such a purpose. It includes my edits to make a one-line version.

/* Add Template:Categorybrowsebaroneline to top of page */

setTimeout("categorybrowsebaroneline()", 0);

function categorybrowsebaroneline() { var div = document.createElement("div");

div.innerHTML = '

<a href="/wiki/Category:Culture" title="Category:Culture">Culture</a> | <a href="/wiki/Category:Geography" title="Category:Geography">Geography</a> | <a href="/wiki/Category:History" title="Category:History">History</a> | <a href="/wiki/Category:Personal_life" title="Category:Personal life">Life</a> | <a href="/wiki/Category:Mathematics" title="Category:Mathematics">Mathematics</a> | <a href="/wiki/Category:Science" title="Category:Science">Science</a> | <a href="/wiki/Category:Human_societies" title="Category:Human societies">Society</a> | <a href="/wiki/Category:Technology" title="Category:Technology">Technology</a> | <a href="/wiki/Wikipedia:Browse" title="Wikipedia:Browse">Categories</a> | <a href="/wiki/Portal:Browse" title="Portal:Browse">Portals</a> | <a href="/wiki/Wikipedia:Browse_by_overview" title="Wikipedia:Browse by overview">Articles</a> | <a href="/wiki/Wikipedia:Quick_index" title="Wikipedia:Quick index">Alpha</a> | <a href="/wiki/Wikipedia:Category_schemes" title="Wikipedia:Category schemes">More</a>

'

document.getElementById("content").insertBefore(div, document.getElementsByTagName("h1")[0]);

}

Two menu version

Use this (template:eight portals links) across the top of a page.

Art | Culture | Geography | History | Mathematics | People | Philosophy | Science | Society | Technology

Add the browse options to the sidebar navigation box something like this.

navigation

• Main Page
• Community portal
• Current events
• Recent changes
• Alphabetical index
• Ask a question
• Browse articles
• Browse categories
• Browse portals
• Other indexes
• Random article
• Help
• Contact us
• Donations

Navigationboxes not working anymore

The recent changes of the monobook seem to hide some navigational boxes completely - e.g. Template:Provinces of Thailand. The main difference between that one and those which still show is that the invisible include a id="toc". Yesterday they still showed, however due to the caching of the css I'm not sure which change actually was the "bad" one. Where is the problem - within the css or the template? andy 11:09, 27 September 2005 (UTC)

That template is visible to me - I'm using IE6.0 at the moment. What's your browser? Worldtraveller 11:21, 27 September 2005 (UTC)

Firefox 1.0.6 andy 11:22, 27 September 2005 (UTC)

Strange, now they are back, and nothing was changed in the css. andy 16:08, 27 September 2005 (UTC)

underlined links?

Looking at m:Link style vote the decided policy seems to be underlining links even when the mouse is not over a link, however I see that this behaviour has been reverted by ABCD. The justification he invokes is "allow browser settings to propagate". But, as you can see in monobook/main.css on line 66:

a
{
    text-decoration: none;
    ...
}

This means that browser settings won't propagate, and that links will never be underlined, regardless of what the browser settings are. Note that this only occurs when not logged in (otherwise it depends only on the user's preferences), and that Firefox's Web Developer Toolbar confirms that this is indeed the reason why links are not underlined. Unless monobook/main.css can be modified to fix this, I believe this change should be reverted... Or maybe there was another discussion of this issue? (in which case m:Link style vote should be updated) --Ma Baker 02:08, 8 November 2005 (UTC)

Need diff colors that are compatible with color-blind people

Since a large portion of people are color blind in some sense, we should address this quickly:

(copied from User talk:Jimbo Wales)

---

Hi Mr. Wales, or Jimbo, which ever you prefer.

I'm just inquiring about a recent change in the edit thingy. When you enter into "History" of an article & then click on the "Compare Selected Changes" button, the changes were shown in dark red. But now they are hardly visible, & for an editor with colourblindness, it is quite hard to see what changes people have made to the article. Could you please supply me with an answer if this will be changed or remedied or if it will stay the same.

I would have posted this on the appropiate page, but I do not know of one, so selected you because you are the "Main Man" on Wikipedia I suppose.

Regards, Spawn Man 23:15, 7 December 2005 (UTC)

---

— BRIAN0918 • 2005-12-8 00:04

Apropos of this, would it be possible to fix it so that the background-color also changes, to allow alterations in white-space to be seen? HTH HAND —Phil | Talk 08:23, 2 February 2006 (UTC)

Site notice now to the right of page title

I was told that here is the place to say this, so sorry if it isn't. May I suggest the hearder be moved back to the top of the page where it used to be, rather than at the right of the page title. The first time I saw it like that I thought it was a bug; I really do think it looks terrible. If I'm understanding the code in the history correctly it's been changed and reverted, and it's only a test, but my view is don't keep it like this! Why was it moved to the right in the first place anyway? Raven4x4x 08:52, 23 December 2005 (UTC)

Margin around image box

In, Firefox, left-floated image boxes nearly overlap the text above. I suggest that a margin-top is added:

div.thumb {

   margin-bottom: 0.5em;
   margin-top: 0.5ex;
   border-style: solid; border-color: White;
   width: auto;

}

--84.194.112.7 17:57, 11 January 2006 (UTC)

Spoken

Can somebody revert the spoken code to:

#spoken {
 display: block !important;
 border-bottom-style: none;
 float: right;
 position: absolute;
 right: 2%;
 top: 0.6em;
}

The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)

Requesting again, this never got done. Joe D (t) 02:05, 17 January 2006 (UTC)

Would this code work when there are announcements in the heading, like during the recent fundraiser or with Jimbo's appeal for donations? ~MDD4696 05:15, 17 January 2006 (UTC)

Usually. The modified code was supposed to make it change depending on the site notice, but merely broke it. A simple temporary fix is easily implemented while the site notice is enabled. Joe D (t) 05:36, 17 January 2006 (UTC)