Archives

June 2004 - October 2005 June 2005 - December 2005 July 2005 - April 2006 May 2006 - December 2007 December 2007 - Current

Is this diff code still needed? — RockMFR 01:52, 19 September 2009 (UTC)[reply]

Depends on wether we think it was a successful experiment I guess :D I use my own colorcoding CSS for diff. —TheDJ (talk • contribs) 16:42, 17 November 2009 (UTC)[reply]

It is still needed, in fact, parts of it could serve well in vector.css, especially the font-size and vertical-align. — Edokter • Talk • 23:16, 18 October 2010 (UTC)[reply]

Look at me, replying to a year old message. :) — Edokter • Talk • 23:28, 18 October 2010 (UTC)[reply]

Would it be helpful to add personalized CSS for some pages? Chairsenses (talk) 02:59, 16 January 2010 (UTC)[reply]

I don't know, would it?? :P Happy‑melon 13:20, 16 January 2010 (UTC)[reply]

This class has margin-top: 1em; by default, tracing a half-height alleyway below the last navbox. I think positioning these elements flushly would be an aesthetic improvement. What kind of CSS would collapse these borders most effectively, to make figure 1 (left) resemble figure 2 (right) in the following screen-shot?

• See http://i54.tinypic.com/2a95gd5.png (content from Deion Sanders)

Perhaps we could set margin-top:0px; for the catlinks, and margin-bottom:-1px; for all navboxes, noting that navboxes should have no free-form content below them, only other navboxes. This might be IE6 friendly, even. ―cobaltcigs 16:02, 18 October 2010 (UTC)[reply]

If we set margin-top:0px; for the category boxes, everything will cling to the box, including what you are reading right now; we defenitely do not want that. The category box is a seperate entity on the page; it should remain that way. — Edokter • Talk • 23:00, 18 October 2010 (UTC)[reply]

Fully agreed with Edokter. Having text run into the top of the catlinks seems a really bad idea. Not every page has navboxes. (And even then, i'd like to keep seperation between the two elements). —TheDJ (talk • contribs) 23:26, 18 October 2010 (UTC)[reply]

Could we reduce it to a few px so it is not visually mistakable for an empty paragraph tag? ―cobaltcigs 23:54, 21 November 2010 (UTC)[reply]

I'm afraid not. 1em is the default spacing between article content and all other elements. — Edokter • Talk • 00:12, 22 November 2010 (UTC)[reply]

#coordinates {
  /* Increase clicking area for selecting coordinates */
  padding-right:30px;
  right:0;
}

— Dispenser 00:00, 2 July 2012 (UTC)[reply]

Done Seems sensible, and shouldn't cause any change in the actual display Anomie⚔ 01:24, 10 July 2012 (UTC)[reply]

Hi. Can someone please look at updating the following text:

/* Don't display some stuff on the main page */
body.page-Main_Page #deleteconfirm,
body.page-Main_Page #t-cite,
body.page-Main_Page #lastmod,
body.page-Main_Page.action-view #siteSub,
body.page-Main_Page.action-view #contentSub,
body.page-Main_Page.action-view h1.firstHeading {
    display: none !important;
}
/* The above causes the bodyContent div to cover most of the 
   tabs on the main page, making them unclickable. Shifting 
   it down a bit fixes the problem. */
body.page-Main_Page.action-view #bodyContent{
    margin-top: 1.3em;
}

with this text:

/* Don't display some stuff on the main page */
body.page-Main_Page #deleteconfirm,
body.page-Main_Page #t-cite,
body.page-Main_Page #lastmod,
body.page-Main_Page.action-view #siteSub,
body.page-Main_Page.action-view #contentSub,
body.page-Main_Page.action-view h1.firstHeading {
    display: none !important;
}

please?

margin-top on bodyContent came from this edit. I believe this was a misdiagnosis of the underlying issue. The issue is that the "#jump-to-nav" element obscures the tabs in Monobook. Adding margin-top makes the page look silly (though this seems to have become more apparent just recently). --MZMcBride (talk) 02:51, 23 April 2013 (UTC)[reply]

Just removing the margin-top might be sufficient here. Does nobody else see the extra space above the "Welcome to Wikipedia" banner here: <https://en.wikipedia.org/wiki/Main_Page?useskin=monobook>? --MZMcBride (talk) 02:56, 23 April 2013 (UTC)[reply]

Okay, I tested in Chrome, Safari, and Firefox and the margin-top definitely seems to be to blame here. If I remove it, the extra space goes away and the tabs are still clickable. --MZMcBride (talk) 03:01, 23 April 2013 (UTC)[reply]

Done. Thanks for the fix! It's been a long time since I've used the good old Monobook skin. Ah, the nostalgia... I'll be watching when the update kicks in, but please don't hesitate to let me know if any issues crop up, in case I miss anything. Best — Mr. Stradivarius ^{♪ talk ♪} 09:39, 23 April 2013 (UTC)[reply]

(edit conflict) My Firefox recently "upgraded" from v19 to v20: they have significantly changed the "inspect element" feature, and I'm still finding my way around it. It's definitely the margin-top: property of the <div id=bodyContent> although reading the display one way (the new "box model" feature), it's 16px; another way ("Computed"), shows margin-top 16.5167px; a third ("Rules") shows

body.page-Main_Page.action-view #bodyContent {
    margin-top: 1.3em;
}

i.e. as shown above - but apparently it comes from load.php:1 not Monobook.css --Redrose64 (talk) 09:47, 23 April 2013 (UTC)[reply]

I'll defer to both of you on the css, but I just wanted to say that I am also currently running Firefox 20, and I noticed a distinct reduction of whitespace at the top of the main page in Monobook after I made the edit. — Mr. Stradivarius ^{♪ talk ♪} 13:33, 23 April 2013 (UTC)[reply]

Per Wikipedia:Village pump (proposals)/Archive 109#Move Pending Changes dropdown in header 20 pixels to the left and Template talk:Pp-meta#Overlapping icons, please change line 164 from right: 55px; to right: 75px;. Jackmcbarn (talk) 21:34, 3 March 2014 (UTC)[reply]

 Done. — Edokter (talk) — 23:36, 3 March 2014 (UTC)[reply]

@Edokter: There is a problem here. At Carl Linnaeus, in Monobook, the white padlock obscures the closing parenthesis of the "Accepted (latest)" dropdown, and part of the arrow-down image to the right of that. Although I have both of the gadgets "Add an [edit] link for the lead section of a page" and "Move section [edit] links to the right side of the screen" enabled, disabling either one or both of these makes no difference to the position of the whitelock relative to the dropdown. --Redrose64 (talk) 15:14, 5 March 2014 (UTC)[reply]

I could move it further to the left (110px). But this is an inherent problem with topicons; all the elements need to have their own position specified. — Edokter (talk) — 15:26, 5 March 2014 (UTC)[reply]

Looks much better now, Thank you --Redrose64 (talk) 15:35, 5 March 2014 (UTC)[reply]

Can someone make the coordinates either appear on top or bottom of the centralnotice banners, instead of overlapping with them? See [1] [2]. This problem is not present in dewiki [3] but at dewiki the coordinates are on top of h1 while here at enwiki they're at the bottom of h1. If the local css here cannot be modified to fix this, it would be greatly appreciated if someone could provide the css to fix it through css of cnbanners. But if the latter option is preferred, it would mean that the styling have to be applied to all cnbanners to fix the issue. Thanks, --Glaisher (talk) 17:56, 29 August 2014 (UTC)[reply]

I also have this problem, and have raised the issue at WP:VPT. —Kusma (t·c) 15:55, 8 September 2014 (UTC)[reply]

Please add the following fragment to improve the display of coordinates while the visual editor is open using monobook. The visual editor is basically using the new 'Vector' style of positioning elements inside the canvas.

.ve-ce-surface #coordinates {
    top: 0;
    padding: 0;
}

—TheDJ (talk • contribs) 09:44, 9 November 2015 (UTC)[reply]

 Done. Welcome back? — Martin (MSGJ · talk) 12:43, 9 November 2015 (UTC)[reply]

I've added bolding to new OOUI style buttons that appear in a new light red, making them harder to see, currently this is only done for buttons that you may want to avoid, or may need to find better such as CANCEL/RESET/etc. — xaosflux ^Talk 02:27, 1 December 2017 (UTC)[reply]

Hi, I plan on removing this section absent any objection:

/* Bold 'edit this page' link to encourage newcomers */
#ca-edit a {
	font-weight: bold !important;
}

"Newcomers" don't get monobook anymore, and it goes against the rest of the UI to add weight to the current tab. — xaosflux ^Talk 13:08, 28 August 2018 (UTC)[reply]

 Done let me know if any issues. — xaosflux ^Talk 17:01, 29 August 2018 (UTC)[reply]

Barring objects, will be removing this class as useless. Logged out users get vector now, you would have to do a url "&useskin=monobook" while logged out to make the "log in" button change with this now. — xaosflux ^Talk 13:24, 8 September 2018 (UTC)[reply]

 Done — xaosflux ^Talk 01:36, 10 September 2018 (UTC)[reply]

@Xaosflux: The temporary workaround added in the last edit should no longer be needed, can you undo it? Matma Rex talk 20:02, 12 July 2019 (UTC)[reply]

 Undone @Matma Rex: let me know if you see any issues. — xaosflux ^Talk 20:31, 12 July 2019 (UTC)[reply]

Coming from https://phabricator.wikimedia.org/T248137, all mentions of div together with an id selector # can be safely and should be removed. Volker E. (WMF) (talk) 23:48, 19 March 2020 (UTC)[reply]

It's one way of increasing the specificity without resorting to the cop-out of the !important annotation. --Redrose64 🌹 (talk) 23:51, 20 March 2020 (UTC)[reply]

Redrose64 We can just replace them with .mw-body. —TheDJ (talk • contribs) 10:33, 21 March 2020 (UTC)[reply]

Can a small margin be added at the top so that the username/watchlist/etc. aren't pressed so close to the top edge? I tested this out in my common.css and it looks pretty good.

 
body {
	margin-top:5px;
}

should do the trick. It's fairly minor, but I figured I should ask regardless. Edward-Woodrow :) _[talk] 20:24, 28 June 2023 (UTC)[reply]

One of the reasons that MonoBook is preferred by myself and others is that it doesn't waste nearly as much space as Vector (either Legacy or 2022). Forcing that margin upon all of us would waste space when we don't want it wasted. You are free to modify your own monobook.css if you so desire. --Redrose64 🌹 (talk) 22:10, 28 June 2023 (UTC)[reply]

Alright, I guess that makes sense. Thanks, Edward-Woodrow :) _[talk] 22:11, 28 June 2023 (UTC)[reply]