![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 |
Having the light blue background colour on all non-namespace pages makes the categories page look a bit rubbish. The Category trees and lists have white backgrounds, but the rest of the page is light blue. Also any transparent images on their images page obviously show the bg as light blue, which isn't always a problem, but normally looks nicer in white. I don't really see any need for having these with light blue. C hris_huh talk 11:11, 20 December 2007 (UTC)
I'd like to bring back an
earlier discussion
which suggested that monobook/main.css uses the following property for the <pre> tag:
overflow: auto
so that <pre> sections look nicer in some web browsers when they contain long lines of text (an example:
sudo). --
Rpremuz (
talk)
17:37, 1 January 2008 (UTC)
Random832 has added the following class
/* allow disabling of "external" color on internal links in some situations */
#bodyContent .plainlinks2 a.externalhref^="http://en.wikipedia.org" {
color: #002bb8 !important
}
I suggest that we simply make all external links in the plainlinks class which point to /w/ directory are the wikilink blue. Bellow is my renderition of the code with a few improvements.
#bodyContent .plainlinks ahref ^="http://en.wikipedia.org/w/" {
color: #002bb8 !important;
}
I assume that his edit was connected with the new modern skin having a different color for interwiki links. This coloring seem somewhat desirable as {{ tnavbar}} have hard coded that color. The downsides to this maybe that it makes it hard for people to easily see editing links. —— Dispenser 00:57, 30 January 2008 (UTC)
{{
editprotected}}
body.ns--1 table, form table {background: transparent}
/* Give transparent background to table on confirm deletion page */
form#deleteconfirm table {
background-color:transparent;
}
background-color:#F8FCFF;
should be combined into one, 2 rules with background-color:white;
should be combined into one.
/*Light blue background on all non-article pages; need 32bit color to see difference*/
.
— AlexSm 15:20, 20 March 2008 (UTC)
/* Make content area light blue in all namespaces except articles (main namespace) */
#content,
#p-cactions li a, #p-cactions li a:hover, #p-cactions li.selected a {
background-color: #F8FCFF; /* a light blue */
}
#content div.thumb {
border-color: #F8FCFF;
}
.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
background-color: white;
}
.ns-0 * #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
border-color: white;
}
darker non-main background
#F0FAFF
non-main background
#F8FCFF
mainspace-background
white
I don't really see the point of having non-article pages have a different color background. Most people don't realize there's a difference at all. For those who do, it doesn't really provide much. Would there be any objection to removing it entirely? Should we keep the mainspace different to the other namespaces, or make them all white?
Happy‑
melon 18:16, 25 March 2008 (UTC) --
MZMcBride (
talk)
04:04, 25 March 2008 (UTC)
I have been racking my brain over why different browsers show different base font sizes, ofter correcting fontsize in different templates to make them look the same in most browsers. I did some tracing and finally found the root of the problem... litterally. /skins-1.5/monobook/main.css has the base BODY
font declared as FONT: x-small sans-serif
, only to be upscaled to 127% again in the globalWrapper div declaration. Using x-small
is a very bad starting point, as each browser handles it differently. Playing with overriding these values (by using a fixed value instead), I found that consistency between browsers is indeed possible.
Would it be desireable to file a bugzila request to have it changed so that it uses only one base font declaration (62% in the body) instead? What are other's thoughts? — Edokter • Talk • 18:01, 17 April 2008 (UTC)
Anyway, it should be possible to test Edokter's suggestion by adding
body.mediawiki { font-size: 62.5% }
into your monobook.css. What we really need here is a side-by-side comparison of screenshots from as many browsers as possible, including old and esoteric ones (cellphone browsers, anyone?), with different screen resolutions and default font sizes. — Ilmari Karonen ( talk) 19:46, 19 April 2008 (UTC)
Per discussion at Wikipedia:Village pump (proposals)#Replace "+" with "add new comment" the talk page add section tab "+" was renamed to "new section". (See the top of this page for an example.) That means that it needs the same padding as the other tabs. Thus I added this code today:
#p-cactions #ca-addsection a {
padding-left: .8em;
padding-right: .8em;
}
Note that this code really belongs here and should not be moved to Common.css. To see the new correct padding you might need to refresh your web browser cache. This is due to that MediaWiki:Monobook.css is set to be cached in web browsers for 30 days.
-- David Göthberg ( talk) 22:01, 19 April 2008 (UTC)
I'm proposing the addition of
ul.permissions-errors > li {list-style: none;}
ul.permissions-errors {margin:0}
to Monobook.css in order to remove the bullets in front of the protection messages. Thoughts? -- MZMcBride ( talk) 00:38, 3 May 2008 (UTC)
list-style:none;
might not be enough for some browsers (maybe IE again)? And the weirdest thing that it's currently <div class="permissions-errors">
on another project. —
AlexSm
04:23, 3 May 2008 (UTC)
I've removed padding-left:4px from the siteNotice id. It was added years ago, and doesn't serve any particular purpose. I also changed the margin-bottom of the siteNotice to -.5em. Negative margins should degrade gracefully in older browsers. The change was made to offset the <h1> padding in main.css. Let me know if there are any issues. Cheers. -- MZMcBride ( talk) 04:05, 7 May 2008 (UTC)
is there a way I can use Stylish to give every site i view wikipedia's monobook skin. – ThatWikiGuy ( talk) 20:48, 8 May 2008 (UTC)
A couple months ago, the category height was changed. What affected this? How can I can I emulate the change on my own wiki? A response on my talk page would be quite appreciated. Thanks. -- Emesee ( talk) 00:16, 16 May 2008 (UTC)
I have noticed that the default table background in the monobook skin is white. (That is, for plain tables that don't set any colours or don't use the "wikitable" class and so on.) And since we use a slight blue background in all namespaces except main (article) space then the tables get a visible white background on all those pages. Like this:
{| | Cell 1 | Cell 2 |}
Which at the moment renders a table with a white background:
Cell 1 | Cell 2 |
This also gets very visible on category pages, since the lists with subcategories and pages are built with tables. See any non-empty category page for that, for instance Category:Wikipedia maintenance.
The white table background was added long ago to monobook/main.css to prevent that other content bleed through when a table overlaps it. For instance when a right floating table overlaps the bottom border of a level two heading. I think I agree with that fix.
However, we should of course make the fix work right for our light blue pages. Thus I want to add this code to the "LIGHT BLUE SECTION" of MediaWiki:Monobook.css:
#content table {
background-color: #F8FCFF; /* Light blue */
}
.ns-0 #content table {
background-color: white; /* Set back to white for articles */
}
I have of course tested this in my personal /monobook.css.
While I am at it I would like to remove all the unnecessary *
in that section. That is change this:
.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
background-color: white;
}
.ns-0 * #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
border-color: white;
}
To this:
.ns-0 #content,
.ns-0 #p-cactions li.selected a, .ns-0 #p-cactions li a:hover {
background-color: white;
}
.ns-0 #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 #content div.thumb {
border-color: white;
}
Or am I missing something?
-- David Göthberg ( talk) 15:55, 29 August 2008 (UTC)
#content table {
background-color: transparent;
}
#p-cactions li a {
background-color: #F7F9FB; /* Light blue-gray tabs for other pages */
}
#content,
#p-cactions li a:hover, #p-cactions li.selected a,
#content div.thumb, #content table {
background-color: #F8FCFF; /* Light blue */
}
#p-cactions li a {
background-color: #F7F9FB; /* Light blue-gray inactive tabs */
}
.ns-0 #content,
.ns-0 #p-cactions li a:hover, .ns-0 #p-cactions li.selected a,
.ns-0 #content div.thumb, .ns-0 #content table {
background-color: white; /* Set back to white for articles */
}
.ns-0 #p-cactions li a {
background-color: #FBFBFB; /* Light gray inactive tabs in articles */
}
Currently images in galleries in articles get white padding, and transparent images get white background.
And when galleries are shown on non-article pages the images get light blue padding, and transparent images get light grey background. This is so both for galleries made with the gallery tag and automatic galleries on category pages. An example is Category:Wikipedia image placeholders which has many transparent images.
I intend to change the colours to this instead:
1: Galleries in articles, user pages and portals should get light grey padding, and transparent images should get white background. This is slightly toned down compared to the current white padding, and it helps seeing the actual borders of transparent images.
2: Galleries on other pages, such as category pages, also should get light grey padding. But transparent images should get chequered background, with fall-back to white background if the chequered background image does not load.
The chequered background makes it easy to see which images are transparent and what parts of the images are transparent. I intend to use a softened version of the chequered background that is currently used on image pages, since I think the current version interferes too much with the images.
Since the chequering is slightly ugly I don't want to use it on articles, user pages and portals. I expect that most editors want good looks before function on such pages.
Here is the code for all that:
/* Setting the backgrounds for galleries. */
#content .gallerybox div.thumb {
background-color: #F9F9F9; /* Light gray padding */
}
.gallerybox .thumb img {
background: white url("http://upload.wikimedia.org/wikipedia/en/a/a2/Checker-soft.png") repeat;
}
.ns-0 .gallerybox .thumb img, /* Articles */
.ns-2 .gallerybox .thumb img, /* User pages */
.ns-100 .gallerybox .thumb img { /* Portals */
background: white; /* No chequered background */
}
I just noticed that Commons have set their galleries to the same colours and a chequered background. And they have set it for all their skins by placing it in MediaWiki:Common.css, I think we should do the same.
-- David Göthberg ( talk) 03:21, 1 September 2008 (UTC)
There is no {{ Spoken Article}} please remove refence to it in the absolute section, or replace it with a template like {{template:Coord}} Odessaukrain ( talk) 14:33, 20 October 2008 (UTC)
/* For positioning icons at top-right, used in Templates
"Spoken Article" and "Featured Article" */
/* For positioning icons at top-right, used in
spoken article and featured article templates. */
The MediaWiki:Sitenotice (currently with the message "Help shape the future of Wikipedia...") has a visible white background, when shown on other pages than articles when using the Monobook skin. This is a side effect of the light blue background in Monobook on "other pages" combined with the setting to use white background as default for tables in monobook/main.css.
Only logged in users see this at the moment. Since currently there is a MediaWiki:Anonnotice with the same content that overrides the sitenotice for the IP users, and the anonnotice is transparent.
Also, the current CSS for the sitenotice has two oddities:
1: It has a "background-color: transparent;
" setting for the <div> element, which as far as I understand is unneeded and has no effect. (It is the <table> element that needs to be set to transparent.)
2: Its comment states that it should only "be uncommented during fund-raising drives". That's not good since due to the CSS caching it takes 31 days before all users see a change in these CSS files. Thus such "uncommenting" would have to be done 31 days before a fund-raising drive. Besides, the sitenotice is used for more than just fund-raising.
Here is the current code in MediaWiki:Common.css:
/* Donations link to be uncommented during fund-raising drives */
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
text-align: center;
background-color: transparent;
}
I intend to change it to:
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
text-align: center;
}
#mw-dismissable-notice {
background: transparent;
}
I have tested it in my user space.
-- David Göthberg ( talk) 14:05, 29 October 2008 (UTC)
text-align:center
simply duplicates the rule in
skins-1.5/monobook/main.css. —
AlexSm
16:02, 29 October 2008 (UTC)/* Donations link to be uncommented during fund-raising drives */
" is about. It is not about the declaration immediately below it, but about the declaration one step further down:/*
#fundraising {
text-align: center;
border: 1px solid gray;
padding: 5px;
}
*/
/* For sitenotice and fund-raising messages. */
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
}
#mw-dismissable-notice {
background: transparent;
}
#fundraising {
border: 1px solid gray;
padding: 5px;
text-align: center;
}
text-align: center;
" code for the "#fundraising" declaration.Untitled |
---|
Untitled |
---|
Infoboxes are using text-align: justify;, inherited from #article, #bodyContent, #mw-content
.
Justification doesn't look well on such narrow columns and adding <br /> is needed to make text look good.
Is it possible to add text-align: left; for .infobox
to avoid such ugly spacing?
See examples to the right, they are speaking themselves. —Preceding
unsigned comment added by
Angryxpeh (
talk •
contribs)
In MediaWiki talk:Common.css#Request to fix size of Tex equations for html (simple equation) mode, some discussion has been going on wether to have HTML rendered LaTeX formulas the same size as the PNG rendered formulas. There has been no satisfiable outcome, as it is impossible to force static font sizes in some browsers.
What is appearent, and what started the discussion in the first place, is that the HTML rendered formulas (which are primarely used in-line) are too small, due to them using 'serif' as a font, and that doesn't mix well with Monobook's sans-serif. I would like to fix that with adding the below code, making the HTML formulas match in size with the rest of the text. That means that would become . I would like to do so in all skins using a sans-serif font (Chick, Cologne Blue, Modern and Monobook). Thoughts? —
Edokter •
Talk •
21:46, 24 May 2009 (UTC)
.texhtml {
font-size: 125%;
line-height: 1.5em;
}
As OLEDs become more popular, many people will use this setting to save energy. (I use it, and for the most part, it's fine. The main problem is folks with colored signatures that come up as black on black.) But most templates set the background to white, while not setting the foreground (color:) to black (or something other than light green, which is hard to read on a white background. What's the best way to fix this? Should a bot go and edit all templates that set background to white but don't set foreground? Should (could) a bot go and edit (or flag) all signatures that are black on default? Or is there a smarter way? (Edits like this seem pointless.-- Elvey ( talk) 18:46, 31 May 2009 (UTC)
Starting the inevitable discussion about whether GeSHi borders should be reinstated, per Wikipedia:Village_pump_(technical)#GeSHi_update. Here is my suggestion if so:
div.mw-geshi {padding: 1em; margin:1em 0; border: 1px dashed #2f6fab;}
Note that this probably shouldn't be added to MediaWiki:Common.css, as most skins have different borders:
Pre borders: monobook: border: 1px dashed #2f6fab; chick: border: 1px dashed #2f6fab; modern: border: solid 1px #3c78b5; simple: border: solid 1px black; standard: none cologneblue: none myskin: none nostalgia: none
-- Splarka ( rant) 07:53, 24 June 2009 (UTC)
body.skin-monobook div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: black; background-color: #f9f9f9; line-height: 1.1em; } body.skin-modern div.mw-geshi { border: solid 1px #3c78b5; padding: 0.4em; background-color: #f0f0f0; } body.skin-simple div.mw-geshi { margin: 2em; border: solid 1px black; } body.skin-chick div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: Black; background-color: #f9f9f9; line-height: 1.1em; } body.skin-vector div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: black; background-color: #f9f9f9; line-height: 1.1em; }
{{
sudo}}
Uncontroversial change that restores previous behavior. Please add to MediaWiki:Geshi.css. Thanks! -- MZMcBride ( talk) 02:42, 26 June 2009 (UTC)
Comparing the CSS code of the Monobook.css and the Common.css, I found that the class infobox code is repeated. But they're different:
Common | Monobook |
---|---|
.infobox {
border: 1px solid #aaa;
background-color: #f9f9f9;
color: black;
margin: 0.5em 0 0.5em 1em;
padding: 0.2em;
float: right;
clear: right;
}
.infobox td,
.infobox th {
vertical-align: top;
}
.infobox caption {
font-size: larger;
}
|
.infobox {
border: 1px solid #aaa;
background-color: #f9f9f9;
color: black;
}
|
.infobox.bordered {
border-collapse: collapse;
}
.infobox.bordered td,
.infobox.bordered th {
border: 1px solid #aaa;
}
.infobox.bordered .borderless td,
.infobox.bordered .borderless th {
border: 0;
}
|
.infobox.bordered td,
.infobox.bordered th {
border: 1px solid #aaa;
}
|
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
border: 0;
border-top: 1px solid #aaa;
border-right: 1px solid #aaa;
}
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
border: 0;
border-right: 1px solid #aaa;
}
|
/* Styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
border-top: 1px solid #aaa;
border-right: 1px solid #aaa;
}
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
border-right: 1px solid #aaa;
}
|
why is it repeated? Locos epraix ~ Beastepraix 15:24, 24 June 2009 (UTC)
I have removed it. --- RockMFR 15:47, 28 June 2009 (UTC)
Wikipedia on IE6/9x looks for me like the shot to the right (apparently others see it too: see here). The problem is with the font IE6 selects for "sans-serif". The expected one is Arial, but for some reason it doesn't pick it. I suggest an IE6 (or <7) body font-family override from "sans-serif" (main.css) to "Arial, sans-serif" (IE6/IE<7 fixes CSS). I don't see any negative effects this could have besides fixing the problem whenever it happens. Any thoughts? ¤ ehudshapira 23:23, 29 August 2009 (UTC)
So, what about the above? All the objections were assuming IE6 has user-selectable fonts, which isn't the case. My suggestion would either make no difference when the browser uses the expected font, or restore the normal behavior when it picked a random bad font. And it can be limited to older versions. ¤ ehudshapira 15:34, 5 October 2009 (UTC)
On the main page, what were the settings used in order to have the green column the same height as the blue column, regardless the length of the text inside them? -- Alex:D ( talk) 17:25, 15 September 2009 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 |
Having the light blue background colour on all non-namespace pages makes the categories page look a bit rubbish. The Category trees and lists have white backgrounds, but the rest of the page is light blue. Also any transparent images on their images page obviously show the bg as light blue, which isn't always a problem, but normally looks nicer in white. I don't really see any need for having these with light blue. C hris_huh talk 11:11, 20 December 2007 (UTC)
I'd like to bring back an
earlier discussion
which suggested that monobook/main.css uses the following property for the <pre> tag:
overflow: auto
so that <pre> sections look nicer in some web browsers when they contain long lines of text (an example:
sudo). --
Rpremuz (
talk)
17:37, 1 January 2008 (UTC)
Random832 has added the following class
/* allow disabling of "external" color on internal links in some situations */
#bodyContent .plainlinks2 a.externalhref^="http://en.wikipedia.org" {
color: #002bb8 !important
}
I suggest that we simply make all external links in the plainlinks class which point to /w/ directory are the wikilink blue. Bellow is my renderition of the code with a few improvements.
#bodyContent .plainlinks ahref ^="http://en.wikipedia.org/w/" {
color: #002bb8 !important;
}
I assume that his edit was connected with the new modern skin having a different color for interwiki links. This coloring seem somewhat desirable as {{ tnavbar}} have hard coded that color. The downsides to this maybe that it makes it hard for people to easily see editing links. —— Dispenser 00:57, 30 January 2008 (UTC)
{{
editprotected}}
body.ns--1 table, form table {background: transparent}
/* Give transparent background to table on confirm deletion page */
form#deleteconfirm table {
background-color:transparent;
}
background-color:#F8FCFF;
should be combined into one, 2 rules with background-color:white;
should be combined into one.
/*Light blue background on all non-article pages; need 32bit color to see difference*/
.
— AlexSm 15:20, 20 March 2008 (UTC)
/* Make content area light blue in all namespaces except articles (main namespace) */
#content,
#p-cactions li a, #p-cactions li a:hover, #p-cactions li.selected a {
background-color: #F8FCFF; /* a light blue */
}
#content div.thumb {
border-color: #F8FCFF;
}
.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
background-color: white;
}
.ns-0 * #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
border-color: white;
}
darker non-main background
#F0FAFF
non-main background
#F8FCFF
mainspace-background
white
I don't really see the point of having non-article pages have a different color background. Most people don't realize there's a difference at all. For those who do, it doesn't really provide much. Would there be any objection to removing it entirely? Should we keep the mainspace different to the other namespaces, or make them all white?
Happy‑
melon 18:16, 25 March 2008 (UTC) --
MZMcBride (
talk)
04:04, 25 March 2008 (UTC)
I have been racking my brain over why different browsers show different base font sizes, ofter correcting fontsize in different templates to make them look the same in most browsers. I did some tracing and finally found the root of the problem... litterally. /skins-1.5/monobook/main.css has the base BODY
font declared as FONT: x-small sans-serif
, only to be upscaled to 127% again in the globalWrapper div declaration. Using x-small
is a very bad starting point, as each browser handles it differently. Playing with overriding these values (by using a fixed value instead), I found that consistency between browsers is indeed possible.
Would it be desireable to file a bugzila request to have it changed so that it uses only one base font declaration (62% in the body) instead? What are other's thoughts? — Edokter • Talk • 18:01, 17 April 2008 (UTC)
Anyway, it should be possible to test Edokter's suggestion by adding
body.mediawiki { font-size: 62.5% }
into your monobook.css. What we really need here is a side-by-side comparison of screenshots from as many browsers as possible, including old and esoteric ones (cellphone browsers, anyone?), with different screen resolutions and default font sizes. — Ilmari Karonen ( talk) 19:46, 19 April 2008 (UTC)
Per discussion at Wikipedia:Village pump (proposals)#Replace "+" with "add new comment" the talk page add section tab "+" was renamed to "new section". (See the top of this page for an example.) That means that it needs the same padding as the other tabs. Thus I added this code today:
#p-cactions #ca-addsection a {
padding-left: .8em;
padding-right: .8em;
}
Note that this code really belongs here and should not be moved to Common.css. To see the new correct padding you might need to refresh your web browser cache. This is due to that MediaWiki:Monobook.css is set to be cached in web browsers for 30 days.
-- David Göthberg ( talk) 22:01, 19 April 2008 (UTC)
I'm proposing the addition of
ul.permissions-errors > li {list-style: none;}
ul.permissions-errors {margin:0}
to Monobook.css in order to remove the bullets in front of the protection messages. Thoughts? -- MZMcBride ( talk) 00:38, 3 May 2008 (UTC)
list-style:none;
might not be enough for some browsers (maybe IE again)? And the weirdest thing that it's currently <div class="permissions-errors">
on another project. —
AlexSm
04:23, 3 May 2008 (UTC)
I've removed padding-left:4px from the siteNotice id. It was added years ago, and doesn't serve any particular purpose. I also changed the margin-bottom of the siteNotice to -.5em. Negative margins should degrade gracefully in older browsers. The change was made to offset the <h1> padding in main.css. Let me know if there are any issues. Cheers. -- MZMcBride ( talk) 04:05, 7 May 2008 (UTC)
is there a way I can use Stylish to give every site i view wikipedia's monobook skin. – ThatWikiGuy ( talk) 20:48, 8 May 2008 (UTC)
A couple months ago, the category height was changed. What affected this? How can I can I emulate the change on my own wiki? A response on my talk page would be quite appreciated. Thanks. -- Emesee ( talk) 00:16, 16 May 2008 (UTC)
I have noticed that the default table background in the monobook skin is white. (That is, for plain tables that don't set any colours or don't use the "wikitable" class and so on.) And since we use a slight blue background in all namespaces except main (article) space then the tables get a visible white background on all those pages. Like this:
{| | Cell 1 | Cell 2 |}
Which at the moment renders a table with a white background:
Cell 1 | Cell 2 |
This also gets very visible on category pages, since the lists with subcategories and pages are built with tables. See any non-empty category page for that, for instance Category:Wikipedia maintenance.
The white table background was added long ago to monobook/main.css to prevent that other content bleed through when a table overlaps it. For instance when a right floating table overlaps the bottom border of a level two heading. I think I agree with that fix.
However, we should of course make the fix work right for our light blue pages. Thus I want to add this code to the "LIGHT BLUE SECTION" of MediaWiki:Monobook.css:
#content table {
background-color: #F8FCFF; /* Light blue */
}
.ns-0 #content table {
background-color: white; /* Set back to white for articles */
}
I have of course tested this in my personal /monobook.css.
While I am at it I would like to remove all the unnecessary *
in that section. That is change this:
.ns-0 * #content,
.ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
background-color: white;
}
.ns-0 * #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 * #content div.thumb {
border-color: white;
}
To this:
.ns-0 #content,
.ns-0 #p-cactions li.selected a, .ns-0 #p-cactions li a:hover {
background-color: white;
}
.ns-0 #p-cactions li a {
background-color: #FBFBFB;
}
.ns-0 #content div.thumb {
border-color: white;
}
Or am I missing something?
-- David Göthberg ( talk) 15:55, 29 August 2008 (UTC)
#content table {
background-color: transparent;
}
#p-cactions li a {
background-color: #F7F9FB; /* Light blue-gray tabs for other pages */
}
#content,
#p-cactions li a:hover, #p-cactions li.selected a,
#content div.thumb, #content table {
background-color: #F8FCFF; /* Light blue */
}
#p-cactions li a {
background-color: #F7F9FB; /* Light blue-gray inactive tabs */
}
.ns-0 #content,
.ns-0 #p-cactions li a:hover, .ns-0 #p-cactions li.selected a,
.ns-0 #content div.thumb, .ns-0 #content table {
background-color: white; /* Set back to white for articles */
}
.ns-0 #p-cactions li a {
background-color: #FBFBFB; /* Light gray inactive tabs in articles */
}
Currently images in galleries in articles get white padding, and transparent images get white background.
And when galleries are shown on non-article pages the images get light blue padding, and transparent images get light grey background. This is so both for galleries made with the gallery tag and automatic galleries on category pages. An example is Category:Wikipedia image placeholders which has many transparent images.
I intend to change the colours to this instead:
1: Galleries in articles, user pages and portals should get light grey padding, and transparent images should get white background. This is slightly toned down compared to the current white padding, and it helps seeing the actual borders of transparent images.
2: Galleries on other pages, such as category pages, also should get light grey padding. But transparent images should get chequered background, with fall-back to white background if the chequered background image does not load.
The chequered background makes it easy to see which images are transparent and what parts of the images are transparent. I intend to use a softened version of the chequered background that is currently used on image pages, since I think the current version interferes too much with the images.
Since the chequering is slightly ugly I don't want to use it on articles, user pages and portals. I expect that most editors want good looks before function on such pages.
Here is the code for all that:
/* Setting the backgrounds for galleries. */
#content .gallerybox div.thumb {
background-color: #F9F9F9; /* Light gray padding */
}
.gallerybox .thumb img {
background: white url("http://upload.wikimedia.org/wikipedia/en/a/a2/Checker-soft.png") repeat;
}
.ns-0 .gallerybox .thumb img, /* Articles */
.ns-2 .gallerybox .thumb img, /* User pages */
.ns-100 .gallerybox .thumb img { /* Portals */
background: white; /* No chequered background */
}
I just noticed that Commons have set their galleries to the same colours and a chequered background. And they have set it for all their skins by placing it in MediaWiki:Common.css, I think we should do the same.
-- David Göthberg ( talk) 03:21, 1 September 2008 (UTC)
There is no {{ Spoken Article}} please remove refence to it in the absolute section, or replace it with a template like {{template:Coord}} Odessaukrain ( talk) 14:33, 20 October 2008 (UTC)
/* For positioning icons at top-right, used in Templates
"Spoken Article" and "Featured Article" */
/* For positioning icons at top-right, used in
spoken article and featured article templates. */
The MediaWiki:Sitenotice (currently with the message "Help shape the future of Wikipedia...") has a visible white background, when shown on other pages than articles when using the Monobook skin. This is a side effect of the light blue background in Monobook on "other pages" combined with the setting to use white background as default for tables in monobook/main.css.
Only logged in users see this at the moment. Since currently there is a MediaWiki:Anonnotice with the same content that overrides the sitenotice for the IP users, and the anonnotice is transparent.
Also, the current CSS for the sitenotice has two oddities:
1: It has a "background-color: transparent;
" setting for the <div> element, which as far as I understand is unneeded and has no effect. (It is the <table> element that needs to be set to transparent.)
2: Its comment states that it should only "be uncommented during fund-raising drives". That's not good since due to the CSS caching it takes 31 days before all users see a change in these CSS files. Thus such "uncommenting" would have to be done 31 days before a fund-raising drive. Besides, the sitenotice is used for more than just fund-raising.
Here is the current code in MediaWiki:Common.css:
/* Donations link to be uncommented during fund-raising drives */
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
text-align: center;
background-color: transparent;
}
I intend to change it to:
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
text-align: center;
}
#mw-dismissable-notice {
background: transparent;
}
I have tested it in my user space.
-- David Göthberg ( talk) 14:05, 29 October 2008 (UTC)
text-align:center
simply duplicates the rule in
skins-1.5/monobook/main.css. —
AlexSm
16:02, 29 October 2008 (UTC)/* Donations link to be uncommented during fund-raising drives */
" is about. It is not about the declaration immediately below it, but about the declaration one step further down:/*
#fundraising {
text-align: center;
border: 1px solid gray;
padding: 5px;
}
*/
/* For sitenotice and fund-raising messages. */
#siteNotice {
margin-top: 5px;
margin-bottom: -.5em;
}
#mw-dismissable-notice {
background: transparent;
}
#fundraising {
border: 1px solid gray;
padding: 5px;
text-align: center;
}
text-align: center;
" code for the "#fundraising" declaration.Untitled |
---|
Untitled |
---|
Infoboxes are using text-align: justify;, inherited from #article, #bodyContent, #mw-content
.
Justification doesn't look well on such narrow columns and adding <br /> is needed to make text look good.
Is it possible to add text-align: left; for .infobox
to avoid such ugly spacing?
See examples to the right, they are speaking themselves. —Preceding
unsigned comment added by
Angryxpeh (
talk •
contribs)
In MediaWiki talk:Common.css#Request to fix size of Tex equations for html (simple equation) mode, some discussion has been going on wether to have HTML rendered LaTeX formulas the same size as the PNG rendered formulas. There has been no satisfiable outcome, as it is impossible to force static font sizes in some browsers.
What is appearent, and what started the discussion in the first place, is that the HTML rendered formulas (which are primarely used in-line) are too small, due to them using 'serif' as a font, and that doesn't mix well with Monobook's sans-serif. I would like to fix that with adding the below code, making the HTML formulas match in size with the rest of the text. That means that would become . I would like to do so in all skins using a sans-serif font (Chick, Cologne Blue, Modern and Monobook). Thoughts? —
Edokter •
Talk •
21:46, 24 May 2009 (UTC)
.texhtml {
font-size: 125%;
line-height: 1.5em;
}
As OLEDs become more popular, many people will use this setting to save energy. (I use it, and for the most part, it's fine. The main problem is folks with colored signatures that come up as black on black.) But most templates set the background to white, while not setting the foreground (color:) to black (or something other than light green, which is hard to read on a white background. What's the best way to fix this? Should a bot go and edit all templates that set background to white but don't set foreground? Should (could) a bot go and edit (or flag) all signatures that are black on default? Or is there a smarter way? (Edits like this seem pointless.-- Elvey ( talk) 18:46, 31 May 2009 (UTC)
Starting the inevitable discussion about whether GeSHi borders should be reinstated, per Wikipedia:Village_pump_(technical)#GeSHi_update. Here is my suggestion if so:
div.mw-geshi {padding: 1em; margin:1em 0; border: 1px dashed #2f6fab;}
Note that this probably shouldn't be added to MediaWiki:Common.css, as most skins have different borders:
Pre borders: monobook: border: 1px dashed #2f6fab; chick: border: 1px dashed #2f6fab; modern: border: solid 1px #3c78b5; simple: border: solid 1px black; standard: none cologneblue: none myskin: none nostalgia: none
-- Splarka ( rant) 07:53, 24 June 2009 (UTC)
body.skin-monobook div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: black; background-color: #f9f9f9; line-height: 1.1em; } body.skin-modern div.mw-geshi { border: solid 1px #3c78b5; padding: 0.4em; background-color: #f0f0f0; } body.skin-simple div.mw-geshi { margin: 2em; border: solid 1px black; } body.skin-chick div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: Black; background-color: #f9f9f9; line-height: 1.1em; } body.skin-vector div.mw-geshi { padding: 1em; border: 1px dashed #2f6fab; color: black; background-color: #f9f9f9; line-height: 1.1em; }
{{
sudo}}
Uncontroversial change that restores previous behavior. Please add to MediaWiki:Geshi.css. Thanks! -- MZMcBride ( talk) 02:42, 26 June 2009 (UTC)
Comparing the CSS code of the Monobook.css and the Common.css, I found that the class infobox code is repeated. But they're different:
Common | Monobook |
---|---|
.infobox {
border: 1px solid #aaa;
background-color: #f9f9f9;
color: black;
margin: 0.5em 0 0.5em 1em;
padding: 0.2em;
float: right;
clear: right;
}
.infobox td,
.infobox th {
vertical-align: top;
}
.infobox caption {
font-size: larger;
}
|
.infobox {
border: 1px solid #aaa;
background-color: #f9f9f9;
color: black;
}
|
.infobox.bordered {
border-collapse: collapse;
}
.infobox.bordered td,
.infobox.bordered th {
border: 1px solid #aaa;
}
.infobox.bordered .borderless td,
.infobox.bordered .borderless th {
border: 0;
}
|
.infobox.bordered td,
.infobox.bordered th {
border: 1px solid #aaa;
}
|
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
border: 0;
border-top: 1px solid #aaa;
border-right: 1px solid #aaa;
}
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
border: 0;
border-right: 1px solid #aaa;
}
|
/* Styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
border-top: 1px solid #aaa;
border-right: 1px solid #aaa;
}
.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
border-right: 1px solid #aaa;
}
|
why is it repeated? Locos epraix ~ Beastepraix 15:24, 24 June 2009 (UTC)
I have removed it. --- RockMFR 15:47, 28 June 2009 (UTC)
Wikipedia on IE6/9x looks for me like the shot to the right (apparently others see it too: see here). The problem is with the font IE6 selects for "sans-serif". The expected one is Arial, but for some reason it doesn't pick it. I suggest an IE6 (or <7) body font-family override from "sans-serif" (main.css) to "Arial, sans-serif" (IE6/IE<7 fixes CSS). I don't see any negative effects this could have besides fixing the problem whenever it happens. Any thoughts? ¤ ehudshapira 23:23, 29 August 2009 (UTC)
So, what about the above? All the objections were assuming IE6 has user-selectable fonts, which isn't the case. My suggestion would either make no difference when the browser uses the expected font, or restore the normal behavior when it picked a random bad font. And it can be limited to older versions. ¤ ehudshapira 15:34, 5 October 2009 (UTC)
On the main page, what were the settings used in order to have the green column the same height as the blue column, regardless the length of the text inside them? -- Alex:D ( talk) 17:25, 15 September 2009 (UTC)