This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Is this the place to point out that the "My contributions" link doesn't go bold when you're on that page? Stevage 12:38, 15 May 2006 (UTC)
The list items of unordered and ordered lists do not align properly.
Example:
The indention of them is quite different. Could this be modified so that the levels of both unordered and ordered lists are the same at each level?
--
Lady Aleena
talk/
contribs 10:01, 30 May 2006 (UTC)
.diffchange {
font-weight: bold;
background-color: inherit;
}
td.diff-addedline, td.diff-deletedline, td.diff-context {
font-size: 85%;
color: inherit;
}
I would suggest:
.diffchange {
font-weight: bold;
text-decoration: underline;
background-color: inherit;
}
td.diff-addedline, td.diff-deletedline, td.diff-context {
font-size: 85%;
color: inherit;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
}
This will do two things. First, any client that supports pre-wrap
, Mozilla's equivalent -moz-pre-wrap
, or both will refrain from collapsing spacing, which will stop the content from being different from in the edit window. Second of all, it will underline all changes as well as boldfacing them, which will allow spacing changes to be seen.
Thoughts? — Simetrical ( talk • contribs) 23:24, 11 June 2006 (UTC)
An alternative to the underlining is something like background-color: #EEEEFF;
. I'm trying that out now, and find it makes the spacing changes as visible without obscuring underscores or the like. Then again, colorblind people might miss the background differences unless they were more dramatic, so maybe it's not appropriate for the main stylesheet.
Also, it occurs to me that if underlining is kept, the bold could be dropped. — Simetrical ( talk • contribs) 22:21, 28 June 2006 (UTC)
On the Template_talk:Dynamic_navigation_box_with_image#Image_broken page there was an issue where NavHead was being displayed over NavPic. This is due to the 'position: relative' line in the class definition. That line doesn't appear in the original German and other language versions of this class. Do we know what it is being used for? I was able to get around the issue on that template by adding a 'position: relative' style to the NavPic section and settign it to a higher z-index than NavHead, but is this something we should change in the class rather than on individual templates? -- CBD 12:43, 22 June 2006 (UTC)
I would like to propose a change to the font settings for TeX rendered as text (not PNG). Right now, it displays in a serif font, which makes it look drastically different than the surrounding text on many browsers ( ) where the first x is rendered with <math> and the second with italicized HTML. If we add this line
span.texhtml { font-family: sans-serif; }
to the Monobook.css file, then the TeX rendered as text will look identical to the surrounding text, which in my opinion is ideal. Also note that several users have already done this to their personal css file (see User:Jitse Niesen/monobook.css, User:Dmharvey/monobook.css, and many more). It was added to MediaWiki:Common.css on March 14, 2006 and then quickly removed by Omegatron with the summary rv math font change - no consensus yet. Well, now I would like to build a consensus so that it can be added. (By the way, the reason I proposed it here instead of at MediaWiki:Common.css is because I don't think it is a problem with other skins because it is the default monobook css that has texhtml rendered in serif fonts.) — Mets501 ( talk) 22:19, 23 June 2006 (UTC)
span.texhtml
as anything special. It will then be automatically handled like normal text. —
Simetrical (
talk •
contribs) 02:29, 26 June 2006 (UTC)
span.texhtml { font-family: inherit; }
. —
Simetrical (
talk •
contribs) 04:55, 26 June 2006 (UTC)
+
mwtoews
08:47, 17 February 2007 (UTC)I suggest adding the line
table { background-color: transparent; }
Currently, the default background color is white, which doesn't make a lot of sense and looks bad outside of article space. See Special:Movepage/Rabbit (or any Special:Movepage) for an example.
This has been discussed on the village pump here. A suggestion was made to create a new CSS class, but first of all that should be unnecessary and second of all you may as well use inline style if you're going to do that. — Simetrical ( talk • contribs) 22:56, 9 July 2006 (UTC)
I'd like to propose some new formatting for blockquote elements. Although colons are often used for long quotations, blockquote can be typed in manually or entered using a template.
#content blockquote { font-size: 93.75%; margin: 1em 1.6em; } #content blockquote p { line-height:inherit; }
The intent is to provide a slight contrast to set off block quotations from the surrounding text, without any jarring differences. It corresponds to common typographic practice, and I developed this after consulting Bringhurst's Elements of Typographic Style.
The slightly font size corresponds to 15px size in the usual 16px default, but the relative size should work in all situations. The left margin will align neatly with the default setback for an unordered list, and right margin is the same. Line-height inherits to fit in better with surrounding text. Here is an example block quotation formatted this way:
Either the English or the French language may be used by any person in the debates of the Houses of the Legislature and both those languages shall be used in the respective Records and Journals of those Houses; and either of those languages may be used by any person, or in any Pleading or Process, in or issuing from any Court of Canada established under the Constitution Act, 1867, or in or from all or any of the Courts of the Province. The Acts of the Legislature shall be Printed and published in both those languages. (Manitoba Act, Section 23)
Anyone object, or suggest changes? — Michael Z. 2006-08-03 02:28 Z
« Either the English or the French language may be used by any person in the debates of the Houses of the Legislature ... Acts of the Legislature shall be Printed and published in both those languages. » (Manitoba Act, Section 23)
This sounds like a good idea, but it should probably go into Common.css instead of Monobook.css — Ruud 17:47, 4 August 2006 (UTC)
The quotes above appear entirely on one line on Netscape 4. -- ais523 17:33, 24 November 2006 ( U T C)
My nav menu has just become messed up. Using IE7 Beta 2, the clipping between the links of the nav menu has increased to the approximation of double-spaced. Does anyone have any thoughts about this (other than use a different browser...yeah, I tried it in FF both logged out and in--haven't tried it logged out in IE yet--and it was fine). Any thoughts? - Mysekurity 23:49, 14 August 2006 (UTC)
Fix for Preferences (Time tab skrew up in Firefox)
.prefsectiontip { float: left; width: 98% }
-- 82.200.186.14 07:24, 28 August 2006 (UTC)
I've spent 15 minutes searching and can't find the documentation for .NavFrame. Where is it? — Michael Z. 2006-10-31 03:40 Z
Why are NavFrame and NavHead here rather than in common.css? Because of this template:Navigation worked only in monobook skin. As a temporary expediency I've inlined these styles in this template, but it seems to me moving these styles to common.css would be a better fix. Is there some reason not to do this? -- Rick Block ( talk) 13:24, 24 November 2006 (UTC)
I would like to change
td.diff-addedline, td.diff-deletedline, td.diff-context { font-size: 85%; color: inherit; }
to
td.diff-addedline, td.diff-deletedline, td.diff-context { vertical-align: top; font-size: 85%; color: inherit; }
so the text align better. → Aza Toth 18:27, 5 December 2006 (UTC)
Shouldn't this be at the common CSS file, not here? Karl Dickman talk 11:24, 12 December 2006 (UTC)
What is people's opinion on the addition of
.mw-plusminus-pos { color:green; font-weight:bold; }
.mw-plusminus-neg { color:red; font-weight:bold; }
to the css? It would make a recent change like this:
23:55
Danny Dyer (
cur;
last) . . (+4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
look like this:
23:55
Danny Dyer (
cur;
last) . . (+4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
and
23:55
Danny Dyer (
cur;
last) . . (-4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
look like this:
23:55
Danny Dyer (
cur;
last) . . (-4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
— Mets501 ( talk) 00:19, 22 December 2006 (UTC)
According to the W3C CSS Validator [1], these are not valid CSS colors. I suggest we replace darkgreen with #006400 and darkred with #8B0000 per [2], this should let the page pass the validator. HighInBC (Need help? Ask me) 01:03, 10 February 2007 (UTC)
Hi, The default CSS for the HTML-rendered math are breakable (as opposed to using non-breaking spaces). This isn't desirable, since parts of a single equation can appear on more than one line. To fix this, you can edit your Special:Mypage/monobook.css to:
span.texhtml { white-space: nowrap; font-family: serif; }
This idea was hinted to me
here. I proposed this at the
Village pump for the default monobook.css, but not a single comment was posted in reply, and was promptly archived within a week. I don't think it's a poor idea, nor is it controversial at all, so I thought I would add it here to collect more dust. +
mwtoews
08:37, 17 February 2007 (UTC)
This applies to readers who are not logged in. The "Your continued donations keep Wikipedia running!" text blurb in the top right corner of the page is not pushed in far enough to the left. If a user is reading an article which is both featured and spoken, for example DNA, then the spoken article icon overlaps the "g!" of the donation text. I'd suggest either moving the text inwards, or stacking the icons on top of one another. Phuzion 21:02, 24 February 2007 (UTC)
Removal of the "cite this page" link from the Main Page has just come up on
Talk:Main Page and I seem to remember it coming up before (either there or elsewhere). Adding body.page-Main_Page #t-cite
to the list of things not to display on the Main Page (right at the top) would presumably do this? –
Qxz 06:20, 23 March 2007 (UTC)
Why is "cite this article" in the sidebar toolbox on the main page? It just seems embarrassing, especially after all the effort that has clearly gone into making the page near-perfect. Sitewide CSS should remove it, if this line is added to this page:
.page-Main_Page #t-cite {display: none}
— Jack · talk · 06:23, Friday, 23 March 2007
Done. — Ruud 09:52, 23 March 2007 (UTC)
Is there a "wiki" method to mark-up horizontal lists, like that at http://en.wikipedia.org/wiki/A34_road#Former_route, so that they're rendered as an HTML list, styled horizontally? Elsewhere, (for example http://www.westmidlandbirdclub.com/test/) I use something like:
.horizontal { padding: 0; margin-top: 0; margin-left: -1.5em; margin-bottom: 0.5em; margin-right: 0; } .horizontal li { display: inline; font-size: 90%; line-height: 1.5; border-left: 0.1ex solid; padding-left: 0.5em; padding-right: 0.5em; } .horizontal li:first-child { border-left: none; padding-left: 0; }
but I have no idea how to apply that to a list, or to a template for a list, in WikiCode. The border-left separator could, of course, be omitted if so desired.
Ideally, the solution would take the form:
{{starthorizontallist}} *cat *dog ... *horse {{endhorizontallist}} (if required)
Andy Mabbett 19:08, 29 March 2007 (UTC)
(See also discussion at Wikipedia:Village pump (technical)#Horizontal lists - Andy Mabbett 22:36, 29 March 2007 (UTC)
<div class=horizontal>
before the list and </div>
after the list in the article. —
METS501 (
talk) 22:20, 29 March 2007 (UTC)I propose we centre images on the image page. — Ruud 15:24, 1 April 2007 (UTC)
This is a matter of aesthetics and personal preference, of course, but I find a significant amount of whitespace one side to look stranger, especially on small images. — Ruud 15:45, 1 April 2007 (UTC)
Try adding #file { text-align:center; }
to your personal css, and look at the results. It doesn't look good on many images. See for example
Image:Polar to cartesian.svg. —
METS501 (
talk) 17:58, 1 April 2007 (UTC)
Something I run into every so often is trying to locate what has been removed or added in a page change when it is just a period, comma, dash or other very small single character. For instance, take a look at the top changed section in this diff. It takes a little while to realize someone removed the minus sign on the record low temperature. I am suggesting a change in this CSS to add the following two lines to the .diffchange {} CSS selector:
background-color: #FF9999; color: #000000;
I have implemented it on my own monobook.css and it seems to make the above minus sign *much* easier to spot in the diff. -- MattWright ( talk) 00:15, 4 April 2007 (UTC)
.diffchange { background-color: #002bb8; color: #fff; }
— David Levy 01:12, 4 April 2007 (UTC)
Definitely a good idea to color the background. Not sure which colors, though. — Omegatron 02:15, 4 April 2007 (UTC)
Hi David, I'm not too concerned about the specific colors, I just chose the red/black as it appeared to more closely match the pastel look of the yellow/green diff boxes and retain a shade of the red color that .diffchange currently uses, so it's not too stark of a difference for users when they first see it. I'm fine with whatever people prefer and thanks for trying it out! -- MattWright ( talk) 15:06, 4 April 2007 (UTC)
.diffchange {border: 1px dotted gray}
.diffchange {padding: 0px 2px 0px 2px; border: 1px dashed red;}
.diffchange {padding: 0px 2px 0px 2px; border: 1px dashed red; margin: 0px 1px 0px 0px}
Compare history page of Main Page with eg. history page of "Wikipedia" article. There is a difference on top - in case of Main Page there is no (among other things) link "View logs for this page". I guess this line:
body.page-Main_Page #contentSub,
is responsible... What is the reason for this? Thanks. Gen. von Klinkerhoffen 23:00, 1 May 2007 (UTC)
h1.firstHeading
. The contentSub
doesn't seem to have anything inside it on article pages, so I too have no idea why it's hidden on the Main Page. P.S. It was Javascript (to hide stuff on Main Page) until a couple of months ago when MediaWiki introduced additional classes for <body> tag. —
Alex Smotrov 00:04, 2 May 2007 (UTC)
action-history
, action-view
(the default). Hopefully it gets accepted. Update: looks like there was already
another one.
Mike Dillon 00:12, 2 May 2007 (UTC)
Sorry, I meant to put this on MediaWiki talk:Common.css. I'm moving it now. -- ais523 16:14, 17 May 2007 ( U T C)
Is this the script that set's the flowery background behind everything? I was thinking about using it on my Wikia, can I? -- Steinninn talk 01:10, 1 June 2007 (UTC)
Please, add to CSS-file "Justify" for the all texts. —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 13:34, 15 June 2007 (UTC)
You must to see not have to think.)) Wiki isn't place of text-garbages. We can to do nice for the readers. —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 14:21, 15 June 2007 (UTC)
you can see:
body{text-align:justify;}
to your
userContents.css file, that way all websites you visit will have justified text (unless the author thinks that otherwise). —
Dispenser 16:30, 15 June 2007But... If don't have? —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 02:01, 16 June 2007 (UTC)
Could somebody possibley add
/* rounded corners - Mozilla/Firefox only */ .pBody { padding: 0.1em 0.1em; -moz-border-radius-topright: 0.5em; -moz-border-radius-bottomright: 0.5em; } #p-cactions ul li, #p-cactions ul li a { -moz-border-radius-topright: 0.5em; -moz-border-radius-topleft: 0.5em; } #content, .toc { -moz-border-radius-topleft: 0.5em; -moz-border-radius-topright: 0.5em; -moz-border-radius-bottomleft: 0.5em; -moz-border-radius-bottomright: 0.5em; }
for rounded corners on some infoboxes? 77.99.107.117 22:02, 3 July 2007 (UTC) (typos fixed 77.99.107.117 04:42, 4 July 2007 (UTC))
Note that this CSS will not do what the original topic said, putting rounded corners on infoboxes. It will put rounded corners on various interface elements, including the main content area, the sidebar boxes, and the content-action buttons at the top of the article. It will also change padding significantly for no apparent reason. Here's a sample, before:
And after:
Applying it to all corners instead of only two, which was probably the intention to start with, and adding rules to work with non-Gecko browsers:
It looks okay, but I don't care much either way. Of course, those will all look identical except in browsers based on Gecko, and maybe Webkit or KHTML, which I think are the only browsers to have even preliminary implementations of the CSS3 border-radius property. If this is implemented, it should be something like
/* rounded corners for browsers that support them */
.pBody
{
-moz-border-radius: 0.5em;
-khtml-border-radius: 0.5em;
-webkit-border-radius: 0.5em;
border-radius: 0.5em;
}
#p-cactions ul li, #p-cactions ul li a
{
-moz-border-radius-topright: 0.5em;
-moz-border-radius-topleft: 0.5em;
-khtml-border-radius-topright: 0.5em;
-khtml-border-radius-topleft: 0.5em;
-webkit-border-radius-topright: 0.5em;
-webkit-border-radius-topleft: 0.5em;
border-radius-topright: 0.5em;
border-radius-topleft: 0.5em;
}
#content, .toc
{
-moz-border-radius: 0.5em;
-khtml-border-radius: 0.5em;
-webkit-border-radius: 0.5em;
border-radius: 0.5em;
}
This 1) omits the irrelevant padding change, 2) uses the official property names (which should always be done) as well as the property names for experimental implementations of those engines that I've heard have them, 3) fixes the fact that only two corners of the sidebar boxes are rounded, and 4) condenses some excessively verbose rules. — Simetrical ( talk • contribs) 00:26, 4 July 2007 (UTC)
{{
editprotected}}
I would like to suggest to add the following code:
div.thumb { border: none; } div.tright { border: none; margin: 0.5em 0 0.8em 1.4em; } div.tleft { border: none; margin: 0.5em 1.4em 0.8em 0; }
... to get this instead of this effect (the difference is the ugly white border around the thumb). The code is copied from the German wikipedia. Free style 13:02, 4 August 2007 (UTC)
Can we please clean up this CSS page? Please remove the following ∴ Alex Smotrov 19:09, 4 October 2007 (UTC)
#mytabs
: I think it's something very outdated#bodyContent #siteSub a ...
: there are no links in #siteSub.diffchange
- font size and weight are same as in
diff.css, other styles make no differenceform#userlogin table
- there is no such form (it's <div id=userloginForm><form name=userlogin>
, and it's already styled good enough in
main.css).portlet a { text-decoration: none;} .portlet a:hover { text-decoration: underline;}
- doesnt add anything compared to
main.css#p-nav ...
(3 times) - most likely somebody's mistake#editpage-specialchars ...
(2 times) - doesn't add anything new.mw-plusminus-pos, .mw-plusminus-neg
- duplicates
Mediawiki:Common.css{{interwiki-all}}<pre><nowiki>
If you don't want to see special characters list at all ...
{{
editprotected}}
P.S. And I'm pretty sure there are a lot of other useless rules or rules that were supposed to be in Commnon.css ∴ Alex Smotrov 19:09, 4 October 2007 (UTC)
Not a whole lot of response here. I've created a /temp subpage at MediaWiki talk:Monobook.css/temp. Put all edits in there and re-enable the editprotected request or ping me and I'll update the page. Just try to make sure that any changes are cataloged here along with the reason for the change. Cheers. -- MZMcBride 23:39, 7 October 2007 (UTC)
More than half of the current Monobook.css either should be removed or moved into Common.css. It's so easy to thoughtlessly add new rules into these files, but not so easy to clean up the mess afterwards. I'm in the process of editing global CSS/JS files in the project where I have an admin flag and. I thought I could also help English Wikipedia a little. If I'm the only one interested in improving these files here, then I can as well stop trying. I'm making one last attempt, and this time I tried to explain things a bit better. All the following rules can be removed ∴ AlexSm 17:59, 17 October 2007 (UTC)
#bodyContent #siteSub a {
color: #000;
text-decoration: none;
background-color: transparent;
background-image: none;
padding-right: 0;
}
There are no links in MediaWiki:Tagline. This CSS was added in 2004, look at the comment: it was even a different system message at the time.
/* Display "User $1, you are already logged in!"
([[MediaWiki:Alreadyloggedin]]) in red and bold */
div.alreadyloggedin { color: red; font-weight: bold; }
MediaWiki:Alreadyloggedin is an obsolete Mediawiki message, and this should have been inline CSS anyway
form#userlogin {
float: left;
padding: 1em 1em .7em 1em;
background-color: #ffffe6;
border: 2px solid #fc6;
color: #000;
margin-right: 2em;
}
form#userlogin table {
float: left;
background-color: #ffffe6;
color: #000;
}
Look at the
Special:Userlogin: it's structure is <div id=userloginForm><form name=userlogin>
, so the code above is useless.
.portlet a {
text-decoration: none;
}
.portlet a:hover {
text-decoration: underline;
}
/* Special characters list below edit window works better without underlining */
#editpage-specialchars a { text-decoration: none; }
#editpage-specialchars a:hover { text-decoration: underline; }
/* If you don't want to see special characters list at all,
put the following line in your User:You/monobook.css file
(and remove the slash-asterisk comments) */
/* #editpage-specialchars { display: none; } */
This is default links behaviour anyway (see main.css). The tip (long comment) doesn't belong here.
.mw-plusminus-pos {
color: #006400;
}
.mw-plusminus-neg {
color: #8B0000;
}
Duplicates Mediawiki:Common.css
#mytabs li {
background: #F8FCFF;
}
.ns-0 * #mytabs li {
background: white;
}
#mytabs li a {
background-color: #F8FCFF;
}
.ns-0 * #mytabs li a {
background-color: white;
}
This was added in 2004 and related to
∴ AlexSm 17:59, 17 October 2007 (UTC)
Please remove the following:
#p-nav h5 {
display: none;
}
#p-nav .pBody {
padding-right: 0;
}
#p-nav a {
display: block;
width: 100%;
}
added (plus next diff) in January 2005. Unfortunately
MediaWiki:Sidebar's history doesn't go that far, and that user is inactive now. However it's clear from the edit summary that the intent was to remove the header «navigation» from the portlet on the left, and that portlet id was p-nav
(now it's p-navigation
).
/* try adding here, this had no effect in [[MediaWiki:Common.css]] */
.plainlinksneverexpand a.external.text:after {
display: none !important
}
added in September 2005, duplicates exactly same rule in MediaWiki:Common.css
/* Remove padding from external links displayed without icon */
#bodyContent .plainlinks a {padding: 0 !important}
added in March 2005, duplicates this rule in main.css :
#bodyContent .plainlinks a {
background: none !important;
padding: 0 !important;
}
∴ AlexSm 16:19, 18 October 2007 (UTC)
And I believe a lot of code should be moved into Common.css, particularly #content blockquote
, @media print
, and I don't see why .infobox
, defined in
MediaWiki:Common.css, needs any special rules specifically for Monobook skin (code
added) in December 2006 ∴
AlexSm 16:19, 18 October 2007 (UTC)
See
this discussion on the administrators' noticeboard: it seems the hiding of the #contentSub section on the main page makes it confusing if someone creates a redirect to
Main Page. Since the section is normally empty, I see no actual need to hide it. I'd therefore like to propose that the line that reads "body.page-Main_Page #contentSub,
" be removed from this stylesheet. Any objections? —
Ilmari Karonen (
talk) 16:19, 26 October 2007 (UTC)
I'm a little fussy over how text juts uncomfortably close to the sides of boxes in Monobook and throughout Wikipedia. To me, it does not look optically balanced or consistant, and I presume the reson for that is that many of the boxes used on the site are not set with a standard width of padding. For this reason, I propose adjusting the padding on all boxes and containers to this standard style:
padding: 1ex 1em;
It's pretty simple. the top and bottoms of boxes receive 1 ex-unit of padding (an ex-unit is the height of the letter "x" in the base font). Left and right padding would receive 1 em-unit of padding (an em-unit is the width of the letter "M" in size of the base font), a bit more than the height padding for visual balance. The advantage of using ex- and em-units is that the units scale precisely to the base font size. Should a user increase or decrease the browser font size or the base font size in their stylesheet, the units change proportionally along with the font size. Another advantage to this method is that ex- and em-units are supported across all major browsers and are unlikely to cause conflicts.
Here's a small example of the difference in the display of these units:
Messagebox padding before:
Messagebox padding after:
I believe this more generous padding aids readability and improves the appearance without drastic changes to the site's layout or box heights.
If this change is too drastic, the units can be cut down equally:
padding: 0.6ex 0.6em;
Right now, I'm using Safari in Mac OS X, so I don't know how this looks in other browsers, but it shouldn't make too much of a difference. Your thoughts? — Down10 TA CO 23:05, 3 November 2007 (UTC)
padding: 0.6em 1em;
I recently copied a few hundred fonts from an old XP installation to my current reformat, and my mediawiki pages started to look off in Interenet Explorer. I tried to check monobook.css to see if I'd installed some font that's higher in the font family heierarchy, but I don't see a font family in the monobook.cs. Does anyone know what is wrong, or where the font family is? This wasn't a problem on the old Xp install though, so I'm baffled.
Here is an image of the issue; Firefox shows how it used to look in IE and still looks in Fox TheHYPO 09:45, 3 December 2007 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Is this the place to point out that the "My contributions" link doesn't go bold when you're on that page? Stevage 12:38, 15 May 2006 (UTC)
The list items of unordered and ordered lists do not align properly.
Example:
The indention of them is quite different. Could this be modified so that the levels of both unordered and ordered lists are the same at each level?
--
Lady Aleena
talk/
contribs 10:01, 30 May 2006 (UTC)
.diffchange {
font-weight: bold;
background-color: inherit;
}
td.diff-addedline, td.diff-deletedline, td.diff-context {
font-size: 85%;
color: inherit;
}
I would suggest:
.diffchange {
font-weight: bold;
text-decoration: underline;
background-color: inherit;
}
td.diff-addedline, td.diff-deletedline, td.diff-context {
font-size: 85%;
color: inherit;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
}
This will do two things. First, any client that supports pre-wrap
, Mozilla's equivalent -moz-pre-wrap
, or both will refrain from collapsing spacing, which will stop the content from being different from in the edit window. Second of all, it will underline all changes as well as boldfacing them, which will allow spacing changes to be seen.
Thoughts? — Simetrical ( talk • contribs) 23:24, 11 June 2006 (UTC)
An alternative to the underlining is something like background-color: #EEEEFF;
. I'm trying that out now, and find it makes the spacing changes as visible without obscuring underscores or the like. Then again, colorblind people might miss the background differences unless they were more dramatic, so maybe it's not appropriate for the main stylesheet.
Also, it occurs to me that if underlining is kept, the bold could be dropped. — Simetrical ( talk • contribs) 22:21, 28 June 2006 (UTC)
On the Template_talk:Dynamic_navigation_box_with_image#Image_broken page there was an issue where NavHead was being displayed over NavPic. This is due to the 'position: relative' line in the class definition. That line doesn't appear in the original German and other language versions of this class. Do we know what it is being used for? I was able to get around the issue on that template by adding a 'position: relative' style to the NavPic section and settign it to a higher z-index than NavHead, but is this something we should change in the class rather than on individual templates? -- CBD 12:43, 22 June 2006 (UTC)
I would like to propose a change to the font settings for TeX rendered as text (not PNG). Right now, it displays in a serif font, which makes it look drastically different than the surrounding text on many browsers ( ) where the first x is rendered with <math> and the second with italicized HTML. If we add this line
span.texhtml { font-family: sans-serif; }
to the Monobook.css file, then the TeX rendered as text will look identical to the surrounding text, which in my opinion is ideal. Also note that several users have already done this to their personal css file (see User:Jitse Niesen/monobook.css, User:Dmharvey/monobook.css, and many more). It was added to MediaWiki:Common.css on March 14, 2006 and then quickly removed by Omegatron with the summary rv math font change - no consensus yet. Well, now I would like to build a consensus so that it can be added. (By the way, the reason I proposed it here instead of at MediaWiki:Common.css is because I don't think it is a problem with other skins because it is the default monobook css that has texhtml rendered in serif fonts.) — Mets501 ( talk) 22:19, 23 June 2006 (UTC)
span.texhtml
as anything special. It will then be automatically handled like normal text. —
Simetrical (
talk •
contribs) 02:29, 26 June 2006 (UTC)
span.texhtml { font-family: inherit; }
. —
Simetrical (
talk •
contribs) 04:55, 26 June 2006 (UTC)
+
mwtoews
08:47, 17 February 2007 (UTC)I suggest adding the line
table { background-color: transparent; }
Currently, the default background color is white, which doesn't make a lot of sense and looks bad outside of article space. See Special:Movepage/Rabbit (or any Special:Movepage) for an example.
This has been discussed on the village pump here. A suggestion was made to create a new CSS class, but first of all that should be unnecessary and second of all you may as well use inline style if you're going to do that. — Simetrical ( talk • contribs) 22:56, 9 July 2006 (UTC)
I'd like to propose some new formatting for blockquote elements. Although colons are often used for long quotations, blockquote can be typed in manually or entered using a template.
#content blockquote { font-size: 93.75%; margin: 1em 1.6em; } #content blockquote p { line-height:inherit; }
The intent is to provide a slight contrast to set off block quotations from the surrounding text, without any jarring differences. It corresponds to common typographic practice, and I developed this after consulting Bringhurst's Elements of Typographic Style.
The slightly font size corresponds to 15px size in the usual 16px default, but the relative size should work in all situations. The left margin will align neatly with the default setback for an unordered list, and right margin is the same. Line-height inherits to fit in better with surrounding text. Here is an example block quotation formatted this way:
Either the English or the French language may be used by any person in the debates of the Houses of the Legislature and both those languages shall be used in the respective Records and Journals of those Houses; and either of those languages may be used by any person, or in any Pleading or Process, in or issuing from any Court of Canada established under the Constitution Act, 1867, or in or from all or any of the Courts of the Province. The Acts of the Legislature shall be Printed and published in both those languages. (Manitoba Act, Section 23)
Anyone object, or suggest changes? — Michael Z. 2006-08-03 02:28 Z
« Either the English or the French language may be used by any person in the debates of the Houses of the Legislature ... Acts of the Legislature shall be Printed and published in both those languages. » (Manitoba Act, Section 23)
This sounds like a good idea, but it should probably go into Common.css instead of Monobook.css — Ruud 17:47, 4 August 2006 (UTC)
The quotes above appear entirely on one line on Netscape 4. -- ais523 17:33, 24 November 2006 ( U T C)
My nav menu has just become messed up. Using IE7 Beta 2, the clipping between the links of the nav menu has increased to the approximation of double-spaced. Does anyone have any thoughts about this (other than use a different browser...yeah, I tried it in FF both logged out and in--haven't tried it logged out in IE yet--and it was fine). Any thoughts? - Mysekurity 23:49, 14 August 2006 (UTC)
Fix for Preferences (Time tab skrew up in Firefox)
.prefsectiontip { float: left; width: 98% }
-- 82.200.186.14 07:24, 28 August 2006 (UTC)
I've spent 15 minutes searching and can't find the documentation for .NavFrame. Where is it? — Michael Z. 2006-10-31 03:40 Z
Why are NavFrame and NavHead here rather than in common.css? Because of this template:Navigation worked only in monobook skin. As a temporary expediency I've inlined these styles in this template, but it seems to me moving these styles to common.css would be a better fix. Is there some reason not to do this? -- Rick Block ( talk) 13:24, 24 November 2006 (UTC)
I would like to change
td.diff-addedline, td.diff-deletedline, td.diff-context { font-size: 85%; color: inherit; }
to
td.diff-addedline, td.diff-deletedline, td.diff-context { vertical-align: top; font-size: 85%; color: inherit; }
so the text align better. → Aza Toth 18:27, 5 December 2006 (UTC)
Shouldn't this be at the common CSS file, not here? Karl Dickman talk 11:24, 12 December 2006 (UTC)
What is people's opinion on the addition of
.mw-plusminus-pos { color:green; font-weight:bold; }
.mw-plusminus-neg { color:red; font-weight:bold; }
to the css? It would make a recent change like this:
23:55
Danny Dyer (
cur;
last) . . (+4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
look like this:
23:55
Danny Dyer (
cur;
last) . . (+4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
and
23:55
Danny Dyer (
cur;
last) . . (-4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
look like this:
23:55
Danny Dyer (
cur;
last) . . (-4,033) . .
AntiVandalBot (
Talk |
contribs) (BOT - rv 80.176.133.116 (
talk) to last version by Ashworth66)
— Mets501 ( talk) 00:19, 22 December 2006 (UTC)
According to the W3C CSS Validator [1], these are not valid CSS colors. I suggest we replace darkgreen with #006400 and darkred with #8B0000 per [2], this should let the page pass the validator. HighInBC (Need help? Ask me) 01:03, 10 February 2007 (UTC)
Hi, The default CSS for the HTML-rendered math are breakable (as opposed to using non-breaking spaces). This isn't desirable, since parts of a single equation can appear on more than one line. To fix this, you can edit your Special:Mypage/monobook.css to:
span.texhtml { white-space: nowrap; font-family: serif; }
This idea was hinted to me
here. I proposed this at the
Village pump for the default monobook.css, but not a single comment was posted in reply, and was promptly archived within a week. I don't think it's a poor idea, nor is it controversial at all, so I thought I would add it here to collect more dust. +
mwtoews
08:37, 17 February 2007 (UTC)
This applies to readers who are not logged in. The "Your continued donations keep Wikipedia running!" text blurb in the top right corner of the page is not pushed in far enough to the left. If a user is reading an article which is both featured and spoken, for example DNA, then the spoken article icon overlaps the "g!" of the donation text. I'd suggest either moving the text inwards, or stacking the icons on top of one another. Phuzion 21:02, 24 February 2007 (UTC)
Removal of the "cite this page" link from the Main Page has just come up on
Talk:Main Page and I seem to remember it coming up before (either there or elsewhere). Adding body.page-Main_Page #t-cite
to the list of things not to display on the Main Page (right at the top) would presumably do this? –
Qxz 06:20, 23 March 2007 (UTC)
Why is "cite this article" in the sidebar toolbox on the main page? It just seems embarrassing, especially after all the effort that has clearly gone into making the page near-perfect. Sitewide CSS should remove it, if this line is added to this page:
.page-Main_Page #t-cite {display: none}
— Jack · talk · 06:23, Friday, 23 March 2007
Done. — Ruud 09:52, 23 March 2007 (UTC)
Is there a "wiki" method to mark-up horizontal lists, like that at http://en.wikipedia.org/wiki/A34_road#Former_route, so that they're rendered as an HTML list, styled horizontally? Elsewhere, (for example http://www.westmidlandbirdclub.com/test/) I use something like:
.horizontal { padding: 0; margin-top: 0; margin-left: -1.5em; margin-bottom: 0.5em; margin-right: 0; } .horizontal li { display: inline; font-size: 90%; line-height: 1.5; border-left: 0.1ex solid; padding-left: 0.5em; padding-right: 0.5em; } .horizontal li:first-child { border-left: none; padding-left: 0; }
but I have no idea how to apply that to a list, or to a template for a list, in WikiCode. The border-left separator could, of course, be omitted if so desired.
Ideally, the solution would take the form:
{{starthorizontallist}} *cat *dog ... *horse {{endhorizontallist}} (if required)
Andy Mabbett 19:08, 29 March 2007 (UTC)
(See also discussion at Wikipedia:Village pump (technical)#Horizontal lists - Andy Mabbett 22:36, 29 March 2007 (UTC)
<div class=horizontal>
before the list and </div>
after the list in the article. —
METS501 (
talk) 22:20, 29 March 2007 (UTC)I propose we centre images on the image page. — Ruud 15:24, 1 April 2007 (UTC)
This is a matter of aesthetics and personal preference, of course, but I find a significant amount of whitespace one side to look stranger, especially on small images. — Ruud 15:45, 1 April 2007 (UTC)
Try adding #file { text-align:center; }
to your personal css, and look at the results. It doesn't look good on many images. See for example
Image:Polar to cartesian.svg. —
METS501 (
talk) 17:58, 1 April 2007 (UTC)
Something I run into every so often is trying to locate what has been removed or added in a page change when it is just a period, comma, dash or other very small single character. For instance, take a look at the top changed section in this diff. It takes a little while to realize someone removed the minus sign on the record low temperature. I am suggesting a change in this CSS to add the following two lines to the .diffchange {} CSS selector:
background-color: #FF9999; color: #000000;
I have implemented it on my own monobook.css and it seems to make the above minus sign *much* easier to spot in the diff. -- MattWright ( talk) 00:15, 4 April 2007 (UTC)
.diffchange { background-color: #002bb8; color: #fff; }
— David Levy 01:12, 4 April 2007 (UTC)
Definitely a good idea to color the background. Not sure which colors, though. — Omegatron 02:15, 4 April 2007 (UTC)
Hi David, I'm not too concerned about the specific colors, I just chose the red/black as it appeared to more closely match the pastel look of the yellow/green diff boxes and retain a shade of the red color that .diffchange currently uses, so it's not too stark of a difference for users when they first see it. I'm fine with whatever people prefer and thanks for trying it out! -- MattWright ( talk) 15:06, 4 April 2007 (UTC)
.diffchange {border: 1px dotted gray}
.diffchange {padding: 0px 2px 0px 2px; border: 1px dashed red;}
.diffchange {padding: 0px 2px 0px 2px; border: 1px dashed red; margin: 0px 1px 0px 0px}
Compare history page of Main Page with eg. history page of "Wikipedia" article. There is a difference on top - in case of Main Page there is no (among other things) link "View logs for this page". I guess this line:
body.page-Main_Page #contentSub,
is responsible... What is the reason for this? Thanks. Gen. von Klinkerhoffen 23:00, 1 May 2007 (UTC)
h1.firstHeading
. The contentSub
doesn't seem to have anything inside it on article pages, so I too have no idea why it's hidden on the Main Page. P.S. It was Javascript (to hide stuff on Main Page) until a couple of months ago when MediaWiki introduced additional classes for <body> tag. —
Alex Smotrov 00:04, 2 May 2007 (UTC)
action-history
, action-view
(the default). Hopefully it gets accepted. Update: looks like there was already
another one.
Mike Dillon 00:12, 2 May 2007 (UTC)
Sorry, I meant to put this on MediaWiki talk:Common.css. I'm moving it now. -- ais523 16:14, 17 May 2007 ( U T C)
Is this the script that set's the flowery background behind everything? I was thinking about using it on my Wikia, can I? -- Steinninn talk 01:10, 1 June 2007 (UTC)
Please, add to CSS-file "Justify" for the all texts. —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 13:34, 15 June 2007 (UTC)
You must to see not have to think.)) Wiki isn't place of text-garbages. We can to do nice for the readers. —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 14:21, 15 June 2007 (UTC)
you can see:
body{text-align:justify;}
to your
userContents.css file, that way all websites you visit will have justified text (unless the author thinks that otherwise). —
Dispenser 16:30, 15 June 2007But... If don't have? —The preceding unsigned comment was added by 24.168.39.49 ( talk • contribs) 02:01, 16 June 2007 (UTC)
Could somebody possibley add
/* rounded corners - Mozilla/Firefox only */ .pBody { padding: 0.1em 0.1em; -moz-border-radius-topright: 0.5em; -moz-border-radius-bottomright: 0.5em; } #p-cactions ul li, #p-cactions ul li a { -moz-border-radius-topright: 0.5em; -moz-border-radius-topleft: 0.5em; } #content, .toc { -moz-border-radius-topleft: 0.5em; -moz-border-radius-topright: 0.5em; -moz-border-radius-bottomleft: 0.5em; -moz-border-radius-bottomright: 0.5em; }
for rounded corners on some infoboxes? 77.99.107.117 22:02, 3 July 2007 (UTC) (typos fixed 77.99.107.117 04:42, 4 July 2007 (UTC))
Note that this CSS will not do what the original topic said, putting rounded corners on infoboxes. It will put rounded corners on various interface elements, including the main content area, the sidebar boxes, and the content-action buttons at the top of the article. It will also change padding significantly for no apparent reason. Here's a sample, before:
And after:
Applying it to all corners instead of only two, which was probably the intention to start with, and adding rules to work with non-Gecko browsers:
It looks okay, but I don't care much either way. Of course, those will all look identical except in browsers based on Gecko, and maybe Webkit or KHTML, which I think are the only browsers to have even preliminary implementations of the CSS3 border-radius property. If this is implemented, it should be something like
/* rounded corners for browsers that support them */
.pBody
{
-moz-border-radius: 0.5em;
-khtml-border-radius: 0.5em;
-webkit-border-radius: 0.5em;
border-radius: 0.5em;
}
#p-cactions ul li, #p-cactions ul li a
{
-moz-border-radius-topright: 0.5em;
-moz-border-radius-topleft: 0.5em;
-khtml-border-radius-topright: 0.5em;
-khtml-border-radius-topleft: 0.5em;
-webkit-border-radius-topright: 0.5em;
-webkit-border-radius-topleft: 0.5em;
border-radius-topright: 0.5em;
border-radius-topleft: 0.5em;
}
#content, .toc
{
-moz-border-radius: 0.5em;
-khtml-border-radius: 0.5em;
-webkit-border-radius: 0.5em;
border-radius: 0.5em;
}
This 1) omits the irrelevant padding change, 2) uses the official property names (which should always be done) as well as the property names for experimental implementations of those engines that I've heard have them, 3) fixes the fact that only two corners of the sidebar boxes are rounded, and 4) condenses some excessively verbose rules. — Simetrical ( talk • contribs) 00:26, 4 July 2007 (UTC)
{{
editprotected}}
I would like to suggest to add the following code:
div.thumb { border: none; } div.tright { border: none; margin: 0.5em 0 0.8em 1.4em; } div.tleft { border: none; margin: 0.5em 1.4em 0.8em 0; }
... to get this instead of this effect (the difference is the ugly white border around the thumb). The code is copied from the German wikipedia. Free style 13:02, 4 August 2007 (UTC)
Can we please clean up this CSS page? Please remove the following ∴ Alex Smotrov 19:09, 4 October 2007 (UTC)
#mytabs
: I think it's something very outdated#bodyContent #siteSub a ...
: there are no links in #siteSub.diffchange
- font size and weight are same as in
diff.css, other styles make no differenceform#userlogin table
- there is no such form (it's <div id=userloginForm><form name=userlogin>
, and it's already styled good enough in
main.css).portlet a { text-decoration: none;} .portlet a:hover { text-decoration: underline;}
- doesnt add anything compared to
main.css#p-nav ...
(3 times) - most likely somebody's mistake#editpage-specialchars ...
(2 times) - doesn't add anything new.mw-plusminus-pos, .mw-plusminus-neg
- duplicates
Mediawiki:Common.css{{interwiki-all}}<pre><nowiki>
If you don't want to see special characters list at all ...
{{
editprotected}}
P.S. And I'm pretty sure there are a lot of other useless rules or rules that were supposed to be in Commnon.css ∴ Alex Smotrov 19:09, 4 October 2007 (UTC)
Not a whole lot of response here. I've created a /temp subpage at MediaWiki talk:Monobook.css/temp. Put all edits in there and re-enable the editprotected request or ping me and I'll update the page. Just try to make sure that any changes are cataloged here along with the reason for the change. Cheers. -- MZMcBride 23:39, 7 October 2007 (UTC)
More than half of the current Monobook.css either should be removed or moved into Common.css. It's so easy to thoughtlessly add new rules into these files, but not so easy to clean up the mess afterwards. I'm in the process of editing global CSS/JS files in the project where I have an admin flag and. I thought I could also help English Wikipedia a little. If I'm the only one interested in improving these files here, then I can as well stop trying. I'm making one last attempt, and this time I tried to explain things a bit better. All the following rules can be removed ∴ AlexSm 17:59, 17 October 2007 (UTC)
#bodyContent #siteSub a {
color: #000;
text-decoration: none;
background-color: transparent;
background-image: none;
padding-right: 0;
}
There are no links in MediaWiki:Tagline. This CSS was added in 2004, look at the comment: it was even a different system message at the time.
/* Display "User $1, you are already logged in!"
([[MediaWiki:Alreadyloggedin]]) in red and bold */
div.alreadyloggedin { color: red; font-weight: bold; }
MediaWiki:Alreadyloggedin is an obsolete Mediawiki message, and this should have been inline CSS anyway
form#userlogin {
float: left;
padding: 1em 1em .7em 1em;
background-color: #ffffe6;
border: 2px solid #fc6;
color: #000;
margin-right: 2em;
}
form#userlogin table {
float: left;
background-color: #ffffe6;
color: #000;
}
Look at the
Special:Userlogin: it's structure is <div id=userloginForm><form name=userlogin>
, so the code above is useless.
.portlet a {
text-decoration: none;
}
.portlet a:hover {
text-decoration: underline;
}
/* Special characters list below edit window works better without underlining */
#editpage-specialchars a { text-decoration: none; }
#editpage-specialchars a:hover { text-decoration: underline; }
/* If you don't want to see special characters list at all,
put the following line in your User:You/monobook.css file
(and remove the slash-asterisk comments) */
/* #editpage-specialchars { display: none; } */
This is default links behaviour anyway (see main.css). The tip (long comment) doesn't belong here.
.mw-plusminus-pos {
color: #006400;
}
.mw-plusminus-neg {
color: #8B0000;
}
Duplicates Mediawiki:Common.css
#mytabs li {
background: #F8FCFF;
}
.ns-0 * #mytabs li {
background: white;
}
#mytabs li a {
background-color: #F8FCFF;
}
.ns-0 * #mytabs li a {
background-color: white;
}
This was added in 2004 and related to
∴ AlexSm 17:59, 17 October 2007 (UTC)
Please remove the following:
#p-nav h5 {
display: none;
}
#p-nav .pBody {
padding-right: 0;
}
#p-nav a {
display: block;
width: 100%;
}
added (plus next diff) in January 2005. Unfortunately
MediaWiki:Sidebar's history doesn't go that far, and that user is inactive now. However it's clear from the edit summary that the intent was to remove the header «navigation» from the portlet on the left, and that portlet id was p-nav
(now it's p-navigation
).
/* try adding here, this had no effect in [[MediaWiki:Common.css]] */
.plainlinksneverexpand a.external.text:after {
display: none !important
}
added in September 2005, duplicates exactly same rule in MediaWiki:Common.css
/* Remove padding from external links displayed without icon */
#bodyContent .plainlinks a {padding: 0 !important}
added in March 2005, duplicates this rule in main.css :
#bodyContent .plainlinks a {
background: none !important;
padding: 0 !important;
}
∴ AlexSm 16:19, 18 October 2007 (UTC)
And I believe a lot of code should be moved into Common.css, particularly #content blockquote
, @media print
, and I don't see why .infobox
, defined in
MediaWiki:Common.css, needs any special rules specifically for Monobook skin (code
added) in December 2006 ∴
AlexSm 16:19, 18 October 2007 (UTC)
See
this discussion on the administrators' noticeboard: it seems the hiding of the #contentSub section on the main page makes it confusing if someone creates a redirect to
Main Page. Since the section is normally empty, I see no actual need to hide it. I'd therefore like to propose that the line that reads "body.page-Main_Page #contentSub,
" be removed from this stylesheet. Any objections? —
Ilmari Karonen (
talk) 16:19, 26 October 2007 (UTC)
I'm a little fussy over how text juts uncomfortably close to the sides of boxes in Monobook and throughout Wikipedia. To me, it does not look optically balanced or consistant, and I presume the reson for that is that many of the boxes used on the site are not set with a standard width of padding. For this reason, I propose adjusting the padding on all boxes and containers to this standard style:
padding: 1ex 1em;
It's pretty simple. the top and bottoms of boxes receive 1 ex-unit of padding (an ex-unit is the height of the letter "x" in the base font). Left and right padding would receive 1 em-unit of padding (an em-unit is the width of the letter "M" in size of the base font), a bit more than the height padding for visual balance. The advantage of using ex- and em-units is that the units scale precisely to the base font size. Should a user increase or decrease the browser font size or the base font size in their stylesheet, the units change proportionally along with the font size. Another advantage to this method is that ex- and em-units are supported across all major browsers and are unlikely to cause conflicts.
Here's a small example of the difference in the display of these units:
Messagebox padding before:
Messagebox padding after:
I believe this more generous padding aids readability and improves the appearance without drastic changes to the site's layout or box heights.
If this change is too drastic, the units can be cut down equally:
padding: 0.6ex 0.6em;
Right now, I'm using Safari in Mac OS X, so I don't know how this looks in other browsers, but it shouldn't make too much of a difference. Your thoughts? — Down10 TA CO 23:05, 3 November 2007 (UTC)
padding: 0.6em 1em;
I recently copied a few hundred fonts from an old XP installation to my current reformat, and my mediawiki pages started to look off in Interenet Explorer. I tried to check monobook.css to see if I'd installed some font that's higher in the font family heierarchy, but I don't see a font family in the monobook.cs. Does anyone know what is wrong, or where the font family is? This wasn't a problem on the old Xp install though, so I'm baffled.
Here is an image of the issue; Firefox shows how it used to look in IE and still looks in Fox TheHYPO 09:45, 3 December 2007 (UTC)