MediaWiki talk:Monobook.css

From Wikipedia, the free encyclopedia

MediaWiki:Monobook.css has been protected indefinitely. Use {{editprotected}} on this page to request an edit.

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

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

edit

Archives

June 2004 - October 2005 June 2005 - December 2005 July 2005 - April 2006

Contents 1 My contributions 2 List items 3 diff style suggestions 4 NavHead 5 Span.texhtml 6 Set table background to transparent by default 7 Block quotations 8 Navigational Clipping 9 Fix for Preferences 10 NavFrame 11 NavFrame and NavHead 12 diff align 13 Fundraising notice 14 Words added/removed 15 darkgreen and darkred 16 Suggestion for default monobook.css for nowrap span.texhtml 17 Overlapping text/images 18 Not citing the Main Page 18.1 "cite this article" on the main page 19 Horizontal lists 20 Centering images on image pages 21 Better rendering for .diffchange in diff's...

[edit] My contributions

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)

Woa, I never noticed that before. It would be nice if the link would be bolded while I'm looking at the page, more for aesthetic reasons than for practical ones. Can someone make it happen? AmiDaniel (talk) 07:04, 24 May 2006 (UTC)

This is a php problem, not a CSS problem. Try bugzilla. Dragons flight 07:13, 24 May 2006 (UTC)

This issue has already been reported. — Edward Z. Yang^(Talk) 23:33, 11 June 2006 (UTC)

I just noticed it and I was going to report it on the page. I also noticed the log out link doesn't get bold when clicked. Wait a minute... crap... --SUBZ3R0 ^{( Talk | E-mail )} 06:15, 1 April 2007 (UTC)

[edit] List items

The list items of unordered and ordered lists do not align properly.

Example:

• This is a level 1 unordered list item
  • This is a level 2 unordered list item
    • This is a level 3 unordered list item
      • This is a level 4 unordered list item

1. This is a level 1 ordered list item (note this lines up with a level 2 unordered list item)
   1. This is a level 2 ordered list item (note this lines up with a level 4 unordered list item)
      1. This is a level 3 ordered list item (note this probably lines up with a level 6 unordered list item)
         1. This is a level 4 ordered list item (note this probably lines up with a level 8 unordered list item)

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)

I definitely agree with that. I proposed it at WP:VPR because there doesn't seem to be much activity on this talk page. —Mets501 (talk) 01:59, 11 June 2006 (UTC)

I support that. Incidentally, that would also make new-style references indent the same as old-style references so that they can be used side-by-side better. — Saxifrage ✎ 23:46, 11 June 2006 (UTC)

This has been brought up before (above). Ordered lists have an extra-large left margin to accommodate lists with up to three-digit numbers. If they had the same small margin as unordered lists, then two- and three-digit list numbers would overlap the left rule of the article (e.g. below). —Michael Z. 2006-06-25 21:09 Z

1. This list has a more normal left margin: notice that the left margin of text now aligns correctly with the default unordered list, below.
22. Two-digit numbers fall outside the left margin of text
    999. Sub-item
333. Three-digit numbers collide with the left rule

• Matching this unordered list
  • Sub-item

Why did the discussion above die? It should be continued. I see no reason why this should not be implemented. We have a workaround for the one case where lists are displayed in tables. As far as screwing up previous formatting, it's already screwed up for people using other skins, so we should change it now and make it consistant for the future. —Mets501 (talk) 22:11, 25 June 2006 (UTC)

Thus the bullets should be moved out, not the numbers moved in.

1. This list has a more normal left margin: notice that the left margin of text now aligns correctly with the default unordered list, below.
22. Two-digit numbers work correctly
    999. Sub-item
333. So do three-digit numbers

• Item
• These align correctly
  • So does this subitem

—Simetrical (talk • contribs) 04:54, 26 June 2006 (UTC)

[edit] diff style suggestions

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

Does anyone care? —Simetrical (talk • contribs) 04:58, 26 June 2006 (UTC)

Well, it is annoying that spacing changes are hard to see. But it's even more annoying that some folks make edits that are entirely spacing changes. What a waste of time!

--William Allen Simpson 01:46, 27 June 2006 (UTC)

I don't see why spelling corrections like the addition of a space is a waste of time.

I tried Simetrical's proposal out. I think the underline is sometimes useful (not only for spaces but also for small characters, like a full stop or a comma). It has the disadvantage that underlined text is harder to read. On balance, I think it's an improvement and I'll keep it in my css. The pre-wrap has the annoying feature on my browser (Firefox 1.5.0.4 on Debian Linux) that it adds an empty line before and after changed paragraphs in the diff. Its benefit is not very clear to me, so I'd rather not have it. -- Jitse Niesen (talk) 05:00, 28 June 2006 (UTC)

Without pre-wrap, spaces would be compressed (to nothing at the beginning of the line, or to a single space elsewhere). Generally, this will make spacing changes less visible, unless it's being added where there's no preexisting space.

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)

[edit] NavHead

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)

[edit] Span.texhtml

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)

Support. I've seen sans-serif formulas before, and they worked fine. The only problem would be finding a sans-serif font that covered all the math symbols. However, only do this where the article text font is sans-serif (i.e. only the Monobook skin, and not for the print format or on tlh:). Seahen 20:32, 25 June 2006 (UTC)

Comment: If this is done, just don't define span.texhtml as anything special. It will then be automatically handled like normal text. —Simetrical (talk • contribs) 02:29, 26 June 2006 (UTC)

The problem is that right now it's in MediaWiki's default Monobook.css to render as serif, so if we want it as Sans Serif then we need to overwrite that with Wikipedia's local monobook.css. —Mets501 (talk) 03:39, 26 June 2006 (UTC)

Then set it to span.texhtml { font-family: inherit; }. —Simetrical (talk • contribs) 04:55, 26 June 2006 (UTC)

Yeah, that's good. That will let people keep their personal fonts if they have it in their monobook.css. I would also like to post here the concerns raised by KSmrq posted at Wikipedia talk:WikiProject Mathematics. —Mets501 (talk) 01:50, 27 June 2006 (UTC)

We've seen it before. There's little enthusiasm for a global stylesheet change for two reasons (at least).

1. For an inline formula using <math> tags that happens to force a PNG, the "x" will appear in a serif font, which is also the way it appears in most displayed equations (since the typical display is a PNG); consistency in this case dictates that the HTML should use a serif font as well.
2. Anyone who really cares about using a sans-serif font can do so using using their personal stylesheet, just like the users you noted.

No matter which choice is taken, so long as the monobook body text uses sans-serif and TeX PNGs use serif, we have a conflict. Nor is that the end of it; look at the difference in other characters, such as Greek symbols and operators.

This conflict is unlikely to end with the release of the STIX fonts, as suggested by the following statement:

“Most of the glyphs in the STIX Fonts have been designed in Times-compatible style. Times was first designed under Stanley Morison's direction by Victor Lardent at The London Times in 1932. Many variations of this design have been produced since the original.

“In addition to Times-compatible glyphs, some portions of the STIX Fonts include other design styles such as sans serif, monospace, Fraktur, Script, and calligraphic.”

Thrilling; all of the extra styles except sans serif are essential for TeX. So get used to serif mathematics; it looks to be with us for a long time to come. --KSmrq^T 00:27, 25 June 2006 (UTC)

I've been brewing up a similar idea in my head for a while now, which will end all debates over the serif/sans-serif math fonts ... take a look at TeX fonts with math support to get an idea, which I'll write up in a more formal proposal someday later.+mwtoews 08:47, 17 February 2007 (UTC)

[edit] Set table background to transparent by default

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)

Never mind, someone (Tim Starling) finally fixed the default. —Simetrical (talk • contribs) 04:48, 21 July 2006 (UTC)

[edit] Block quotations

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

I suggest the quotation should start and end with quotation marks. Either "..." or « ... », which start to the left of the margin of the quoted text (not as below).

« 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 clarifies the distinction between the body text and other text (which might possibly be the start of an indented unordered list) and block quotation. However, I'm not a typographer or design professional, so this suggestion could be laughably naïve. WLD 16:27, 4 August 2006 (UTC)

In theory, this can be done in the style sheet using the content:before and content:after psuedo-properties, but I would prefer not to:

• In printed type, block quotations don't have quotation marks
• Quotation marks would always surround the entire block quote, so it would be impossible to add the citation outside of them, as in the example above
• It would be less flexible; as it stands, individual editors can still type any kind of quotation marks if they please
• These properties are not supported by Microsoft browsers

—Michael Z. 2006-08-04 17:15 Z

That's fine - it was just a suggestion, and as you asked for suggestions... Regards WLD 19:57, 4 August 2006 (UTC)

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)

Perhaps a version belongs in common.css, but I made the margins align with the margins of unordered lists defined in the monobook skin. It might just work fine in common.css anway. —Michael Z. 2006-08-04 18:14 Z

See {{quotation}} {{cquote}}, and all the rest in Category:Quotation templates. There should be only one style, and the other templates and styles should be deleted. — Omegatron 20:16, 4 August 2006 (UTC)

I can see how some of those could be useful in special cases, but they are not designed for block quotations in text, and most of their markup is very bad. I pretty much agree that they should go away.

Anyway, they are beside the point here: I'm just talking about tweaking the style applied to plain <blockquote> markup. Perhaps if the format is good, and Bug 6200 and 4827 ever get fixed, then correct HTML blockquotes will get used more. —Michael Z. 2006-08-04 20:32 Z

The quotes above appear entirely on one line on Netscape 4. --ais523 17:33, 24 November 2006 (UTC)

[edit] Navigational Clipping

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)

Nope, tried it logged out. Colors are usual anon's, but the spacing is still ginormous. Clearing cache didn't work either. I imagine it had something to do with Timwi's change, but I'm not sure.. Any help would be appreciated. -Mysekurity 23:51, 14 August 2006 (UTC)

Looks fine for me in IE6; I don't see anything in Timwi's change that could have done anything. Weird. —Mets501 (talk) 01:01, 15 August 2006 (UTC)

Um, whups. I guess that's why it's a beta. After a restart, the nav links look fine. Thanks... -Mysekurity 01:42, 15 August 2006 (UTC)

It looks really good. Good work guys! --Siva1979^{Talk to me} 03:33, 15 August 2006 (UTC)

[edit] Fix for Preferences

Fix for Preferences (Time tab skrew up in Firefox)

.prefsectiontip {
  float: left;
  width: 98%
}

--82.200.186.14 07:24, 28 August 2006 (UTC)

[edit] NavFrame

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

Do you mean something like instructions of use? I don't think any exist - usually people just copy off another example, and modify from there. GeorgeMoney (talk) 03:57, 31 October 2006 (UTC)

Rats. I was modifying Raoulduke47's template, which had <div class="NavFrame"> nested three deep. I presume he copied it from some other example. It didn't look quite right, and I figured out that two of those templates could be just discarded (figured out, by 45 minutes of vainly searching for docs, and 10 minutes of trial-and-error). Too bad somebody put in all that work writing Javascript with no docs. —Michael Z. 2006-10-31 05:17 Z

Be careful; the code is designed to hide navframes once there's at least two of them, and that's been worked around all over Wikipedia by nesting two so as to set it off, which is horribly kludgy and probably based on a misunderstanding of the code in the first place, so check on a page with no other navframes before you try modifying the template even further. The ideal solution would be to replace the script, with documentation this time, and change all uses of it everywhere, but that's unlikely to happen in practice. --ais523 15:42, 31 October 2006 (UTC)

Thanks. I've created a page to start documenting this at Wikipedia:NavFrame. —Michael Z. 2006-10-31 15:45 Z

[edit] NavFrame and NavHead

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)

[edit] diff align

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. _→AzaToth 18:27, 5 December 2006 (UTC)

Done —Mets501 (talk) 15:38, 10 December 2006 (UTC)

[edit] Fundraising notice

Shouldn't this be at the common CSS file, not here? Karl Dickman ^talk 11:24, 12 December 2006 (UTC)

It doesn't show for logged-in users, and anons can't change their skin. --ais523 11:10, 13 December 2006 (UTC)

[edit] Words added/removed

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)

I have copied this css ruleset to common.css, and will remove it from monobook provided that there are no objections. Karl Dickman ^talk 23:43, 24 December 2006 (UTC)

[edit] darkgreen and darkred

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)

Ok, I changed it, now the validator says "Congratulations! No Error Found.". HighInBC ^{(Need help? Ask me)} 13:49, 17 February 2007 (UTC)

The proper css color names, incidentally, are green and maroon --Random832 14:09, 4 April 2007 (UTC)

Ahh, neat. ^High_InBC^{(Need help? Ask me)} 14:11, 4 April 2007 (UTC)

[edit] Suggestion for default monobook.css for nowrap span.texhtml

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 isn't the default behavior for inline LaTeX, at least. Long equations may need to be broken up. —Simetrical (talk • contribs) 19:47, 23 March 2007 (UTC)

[edit] Overlapping text/images

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)

[edit] Not citing the Main Page

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)

Last time it was during the Main Page namespace discussion (in which you participated, if I remember rightly); it was mentioned that the Main Page's cite link was a result of the namespace it was in. --ais523 18:11, 23 March 2007 (UTC)

[edit] "cite this article" on the main page

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)

[edit] Horizontal lists

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)

Very easy to do. Just add that code to the sitewide css and then add <div class=horizontal> before the list and </div> after the list in the article. —METS501 (talk) 22:20, 29 March 2007 (UTC)

"Just add that code to the css" - where? And is it wise (or acceptable) to expect users to insert DIVs? How do we then let people know that that option is availabale to them? Andy Mabbett 22:34, 29 March 2007 (UTC)

I was speaking purely from a technical standpoint. Putting the divs in a template works just as well. The css can be added anywhere in the sitewide css at MediaWiki:Common.css. —METS501 (talk) 22:44, 29 March 2007 (UTC)

Common.css seems to be protected. Andy Mabbett 22:54, 29 March 2007 (UTC)

Yes, and there needs to be community acceptance before the code is added. I suggest suggesting this change at MediaWiki talk:Common.css and possibly WP:VPR. —METS501 (talk) 23:08, 29 March 2007 (UTC)

Thank you. I'd already flagged up this discussion at the former; and have now done so at the latter. Andy Mabbett 23:13, 29 March 2007 (UTC)

Great! —METS501 (talk) 00:19, 30 March 2007 (UTC)

[edit] Centering images on image pages

I propose we centre images on the image page. —Ruud 15:24, 1 April 2007 (UTC)

I think it looks much better on the left. Images that are taller than wide tend to have too much white space on each side otherwise. ^High_InBC^{(Need help? Ask me)} 15:26, 1 April 2007 (UTC)

I agree. It's better on the left. —METS501 (talk) 15:28, 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)

Yes, but images like this: Image:Totem Park pole 2.jpg, look just terrible(a matter of aesthetics and personal preference of course) if centered. ^High_InBC^{(Need help? Ask me)} 15:51, 1 April 2007 (UTC)

Only few images have such extreme propotions. —Ruud 17:05, 1 April 2007 (UTC)

Thousands and thousands of images will have that problem. ^High_InBC^{(Need help? Ask me)} 17:51, 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)

And you might not even think to look in the middle to see a tiny image like Image:X mark 18x18 04.gif. —METS501 (talk) 19:42, 1 April 2007 (UTC)

Those do look pretty bad. ^High_InBC^{(Need help? Ask me)} 19:50, 1 April 2007 (UTC)

That's your opinion. —Ruud 20:24, 1 April 2007 (UTC)

How about, small images are hard to find because they are floating off in nowhere land? ^High_InBC^{(Need help? Ask me)} 20:38, 1 April 2007 (UTC)

The images used in articles are usually at least 180px wide; smaller images will still be right at the top. —Ruud 20:49, 1 April 2007 (UTC)

[edit] Better rendering for .diffchange in diff's...

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)

I like this idea, and I just experimented with some different colors. In my opinion, the best combination that I came across was white text on a dark blue background (the same shade used for our links, so it matches nicely).

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