MediaWiki talk:Monobook.css

(Redirected from MediaWiki talk:Monobook.css/temp)
Latest comment: 1 year ago by Edward-Woodrow in topic Margin

diff code still needed?

edit

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 (talkcontribs) 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. EdokterTalk 23:16, 18 October 2010 (UTC)Reply
Look at me, replying to a year old message. :) EdokterTalk 23:28, 18 October 2010 (UTC)Reply

Personalized CSS

edit

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 Happymelon 13:20, 16 January 2010 (UTC)Reply
edit

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?

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. EdokterTalk 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 (talkcontribs) 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. EdokterTalk 00:12, 22 November 2010 (UTC)Reply

Make selecting coordinate text easier

edit
#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

margin-top on bodyContent

edit

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

Protected edit request on 3 March 2014

edit

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
edit

Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo 09:45, 10 April 2014 (UTC)Reply

#coordinates

edit

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

Protected edit request on 9 November 2015

edit

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 (talkcontribs) 09:44, 9 November 2015 (UTC)Reply

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

OOUI destructive type buttons

edit

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

ca-edit

edit

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

pt-login

edit

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

  Donexaosflux Talk 01:36, 10 September 2018 (UTC)Reply

Undo "Temporary workaround for phab:T226594"

edit

@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

Remove all overly-specified, element dependencies on ids

edit

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 (talkcontribs) 10:33, 21 March 2020 (UTC)Reply

Margin

edit

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