MediaWiki talk:Gadget-site.css

=For reference=

CSS color scheme for this wiki
The following is just a short overview of the current settings to make the classes visible :-) -- :Bdk: 06:42, 17 January 2006 (UTC)

=2006=

New yellow
I'm not sure I like the new yellow - it's a bit garish! --HappyDog 01:06, 18 April 2006 (UTC)


 * I'm not too fond of it either; also, at least one of the developers has referred to it as "urine coloured" and at least one more person has agreed with this view. Rob Church (talk) 18:06, 22 April 2006 (UTC)


 * I know, nobody likes it, me too ;-/ Better suggestions are very welcome, of course. But please keep in mind: We already have enough problems with users who don't understand the different licenses for the namespaces (a lot more hints on this issue have to be written, of course). So this namespace should be "remarkable/striking/whatever" at first glance (NS:Help is in the public domain)), especially for the time being, in which we don't have a namespace-specific sidenotice that is saved with the source if a user saves an article (see bug 4469). We really do need this, and I'm not familiar enough with .js to work out something close within a few days. So an ugly colour seemed to be the best way to get a little more attention for the different namespaces … -- :Bdk: 22:33, 22 April 2006 (UTC)

I've tried something new - a strong blue border around the PD pages. Note that I applied it to Help: only, not to Help_talk:, as I think that PD should not apply to the discussion pages. I have also updated MediaWiki:Copyrightwarning to be clearer, and to stick out more, and have rewritten Project:Copyrights to be clearer and more detailed. I would appreciate it if someone could check that over, as I'm not 100% sure about everything I've written. Hope that makes things a bit better... --HappyDog 12:58, 24 April 2006 (UTC)


 * Hm, looks nicer, definitely, but also less striking (what is not as good IMO). And why do you use border-right: none;, so that it's only a 3/4 border? ;-)
 * But whatever we'll change in the optical way, it is a temporary crook. So I see no other way than creating a proper specific sitenotice for this case (having two licenses in one project) … have to poke someone more *g* -- :Bdk:  14:10, 24 April 2006 (UTC)
 * It's 3/4 border, because that is how it is on all pages. :) What do you reckon to the new copyright notice?  I think it helps a lot. --HappyDog 14:13, 24 April 2006 (UTC)
 * /me hides because of the border ;-) -- :Bdk: 16:58, 25 April 2006 (UTC)

Watermark
I've tried adding a watermark to the PD pages, so there is automatically a mark, even if the PD tag has not been added. To be honest, it looks really bad at the moment, but I'll leave it there for a bit of feedback before deleting. Maybe smaller? Maybe a different location? Different image? We could easily add a small banner that fits into the header section. If we can't get something that both looks good and is clear without being too intrusive then I would suggest scrapping the idea altogether. --HappyDog 15:18, 24 April 2006 (UTC)
 * Well done, much better than the u**** colour, of course. -- :Bdk: 16:58, 25 April 2006 (UTC)

IE 5.5 bug
I've just tested the help namespace in IE5.5, and it looks so very bad - the transparent .png file is not working as it should. I don't know what to suggest, except to fix the background of the image to the background of the namespace. That would fix it but not give us any flexibility in tweaking the ns background. Maybe not a big deal though - once this is sorted I doubt we'll be changing it again. I haven't (can't) test other versions of IE (using FF by the way). --HappyDog 00:18, 26 April 2006 (UTC)

=2007=

Little Bug
When I run the javascript console of firefox 2.0 then I always get a failure message caused by this config.

Please change <pre&gt;<nowiki&gt; to /** <pre&gt;<nowiki&gt; */

and </nowiki&gt;</pre&gt; to /** </nowiki&gt;</pre&gt; */

or something like that.

-- MichaelFrey 05:54, 6 May 2007 (UTC)


 * Thanks, thats good :-) -- MichaelFrey 11:05, 6 May 2007 (UTC)

=2008=

Common.css does not seem to have any impact
Hello, does anybody know why my MediaWiki:Common.css does not make any impact on pages of my wiki? for testing purposes i added the same styles than MediaWiki:Common.css but the pages does not change. can anyone please help me?

this also occurs when i try to edit MediaWiki:Common.js (for adding additional edit buttons). Nothing happens. Will i have to enable this function? Thanks in advance --TurboKanne 13:59, 19 February 2008 (UTC)


 * Older versions of MediaWiki had only skin-specific js/css pages, like MediaWiki:Monobook.js or MediaWiki:Simple.css. System messages Common.css and Commmon.js were added around December 2006. Look at the HTML source of your wiki pages to see if these pages are loaded at all (note that Common.js is called from  "site js" URL. If they are called, check the content inside. If the content is present, get Opera or Firefox, open Error Console and check for js/css errors. —AlexSm 14:45, 19 February 2008 (UTC)

MediaWiki:Monobook.css help page
Is there currently a MediaWiki:Monobook.css help page anywhere? If there is can that be mentioned on MediaWiki:Monobook.css? I can create one at Help:MediaWiki:Monobook.css. Odessaukrain 18:54, 7 April 2008 (UTC)
 * It's CSS specific to the MonoBook skin, as is explained on the default message for that page. I really don't think it needs a PD help page... but if you want to make one feel free. --Skizzerz talk - contribs 00:03, 8 April 2008 (UTC)

Where is common.css??
I am completely new and I cannot find...can someone add the location to the article...Thanks! Do you have to create it in 1.12?? --Jorgusch 14:08, 8 June 2008 (UTC)
 * Since no one else has answered, methinks the following (but haven't proved it works yet, possibly due to caching that's not cleared by CTRL-F5 in IE, seems to happen a bit...)


 * The install of mediawiki puts a bunch of .css files in /skins/common. One of them is not common.css. So I assume you copy the text on the message page into a text editor or html editor, then save the file as common.css in /skins/common.


 * Anyone got any better advice than this? (NB It's an indictment on the attitute to noobies that no one has answered this question yet... I spent 10 minutes googling and looking around for the answer to this most basic question, and it seems everyone just assumes that noobies like me automatically know this stuff somehow...) 04:11, 14 August 2008


 * Actually, I don't think anyone ever saw the question. Haven't found it, I wonder if it's generated from the files in /skins/common Kylu 04:18, 14 August 2008 (UTC)


 * Because I just spent an hour trying to figure this out myself, I thought I might share my "Duh!" moment. Common.css and common.js are pages in the wiki, itself. Enter "Mediawiki:common.css" into the search field and then edit the resulting page.  Now, if this information is wrong (it worked for me) and somebody knows this, by all means, please respond.  I'm stunned there are so many knowledgeable wiki editors, yet this question remained unanswered. Iceofwolf 08:30, 19 December 2008 (UTC)

Modern skin problems
The following parts of the code are causing small problems (basically causing problems with the colors of the tabs on the top of pages in the Manual, Project, and MediaWiki namespaces as well as their talk namespaces) with the Modern skin (and should be moved to MediaWiki:Monobook.css). FunPika 03:07, 27 June 2008 (UTC)
 * This has been fixed. -- :bdk: 21:53, 31 August 2008 (UTC)

Removal of pre tags
I saw the edit note for this change, where scrollbars (overflow: auto) were removed from pre tags. However, this is an incredibly useful functionality - without it many many pages end up with horizontal scrollbars due to the width of the pre sections. Can you explain the problem with this a little further. Perhaps we can work out a solution that solves both issues? --HappyDog 04:37, 29 October 2008 (UTC) If you don't like horizontal scrollbars, just simply customize your personal skin file, but don't disable the access to other people with global rules. — Danny B. 13:55, 29 October 2008 (UTC)
 * There is no pure CSS solution for this. Some JavaScript utilizing drag handling could probably solve it, though. The issue is: If the  is higher than the viewport and top lines are wider than viewport, you have absolutely no chance to get to the overflowing content of them. Besides inner items of the page with their own scrollbars have their invisible content hardly accessible or even inaccessible.