MediaWiki talk:Common.css

Latest comment: 2 years ago by WOSlinker in topic hlist class removal

awesome! – (WT-en) cacahuate talk 21:46, 1 June 2009 (EDT)

MediaWiki:Vector.css edit

Note that we also have custom CSS in MediaWiki:Vector.css.

I feel all that should be moved to MediaWiki:Common.css instead, for simplicity of maintenance. Only CSS that is needed by only Vector Skin and would cause problems for the other skins should be kept in MediaWiki:Vector.css and it should be kept to a minimum. Please keep it simple. --Rogerhc (talk) 22:20, 25 January 2013 (UTC)Reply

Strange inclusion of JavaScript file edit

This piece of code should probably be removed:

<!--[if lt IE 9]>
 
	<script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
 
<![endif]-->
  1. For privacy reasons we should only rely on files served from the WMF's servers, furthermore
  2. I'm a bit doubtful this code has any effect whatsoever, as including a piece of JavaScript into a style sheet doens't seem to be a very useful thing to do.

Ruud 18:13, 19 March 2013 (UTC)Reply

On a related note, I think we should require that anyone adding CSS to this file should always include a comment indicating what that CSS is doing so that we can keep things organized, otherwise we'll never know if something is safe to remove or update. Something like:
 <!-- BEGIN: CSS added for hiding main page title -->
 .css-name1 { ... }
 .css-name2 { ... }
 <!-- END: CSS added for hiding main page title -->
 
In addition to the sorts of issues raised by Ruud, having lots of unused CSS slows page loading, and not being able to easily determine what CSS is in use makes it vastly more difficult to do significant changes in the future. -- Ryan • (talk) • 18:24, 19 March 2013 (UTC)Reply
As far as I can tell the CSS referenced by Ruud, as well as everything removed in this revision is unused CSS that was added for an old version of Main Page New. If that's not the case and this is actually used somewhere then please revert my removal, but please also add a comment in the CSS indicating where exactly the CSS is being used. -- Ryan • (talk) • 03:50, 21 March 2013 (UTC)Reply

New plan for geo edit

Looking at the geo template again, I would really prefer to keep it separate from the banner. It would be better to edit the geo template by itself, especially as it'll be more prone to change. I didn't suggest this before because Javascript wasn't on my mind, but why don't we just insert the geo image directly into the pagebanner instead of merging it in.

1. Change Mediawiki:Common.js first, remove this: importScript( 'MediaWiki:MoveArticleStates.js' );

// current code
$(".topbanner").closest("#mw-content-text").children("#geoCoord").css({top:0});
// new code
$(".topbanner").closest("#mw-content-text").children("#geoCoord").appendTo($(".iconbox"));
$("#geoCoord").css("position","static");

2. For CSS, remove all this (not even being used) from Mediawiki:Common.css

#geoCoord table, #geoCoordOld table {
 border-collapse: collapse;
 background: transparent;
}
 
#geoCoord td, #geoCoordOld td {
 font-size: 0.9em;
 line-height: 100%;
 vertical-align: middle;
 padding: 0 0 0 10px;
 text-align: right;
 border-left: 1px solid #88a;
}
 
#geoCoord td.icon, #geoCoordOld td.icon {
 border-left: none;
 height: 27px;
 width: 35px;
 padding: 0 10px 0 0;
}

3. Replace with this in Mediawiki:Common.css

#geoCoord {
    position: absolute;
    right: 0px;
    float: right;
    padding: 1px 4px 0px 4px;
}

4. Remove this from Mediawiki:Vector.css (not sure why code is even being placed here)

#geoCoord,
#DoM {
 position: absolute;
 z-index: 1;
 right: 12px;
 right: 0;
 top: -36px;
 float: right;
}
 
#DoM {
 top: -4px;
}

Sorry if this is a load of code, but basically the CSS files are kind of in a mess. Pretty sure all the code is right, and following the steps should reduce any noticeable glitches. -- torty3 (talk) 16:37, 29 June 2013 (UTC)Reply

External links icons removed 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

edit

Is the following code really do something?

#toc > tbody > tr > td > ul, #toc > tr > td > ul {
  padding-left: 2em;
}

I wasn't able to find its use. --Andyrom75 (talk) 18:16, 30 November 2014 (UTC)Reply

I looked at both the traditional TOC and the banner TOC, and neither have table tags inside of them. I also tried disabling Javascript and refreshing pages, but the TOC still doesn't have table tags in it. If that code is used anywhere I'm not sure how to trigger it. -- Ryan • (talk) • 18:53, 30 November 2014 (UTC)Reply
I've done the same tests of you without understanding its purpose. I don't have it in it:voy and the pagebanner works correctly. I suggest to delete it also because the following instruction is applicable:
#toc > ul {padding-left: 2em;}
It could be redundant, but at least it works. --Andyrom75 (talk) 00:11, 1 December 2014 (UTC)Reply
  Done [1]. -- Ryan • (talk) • 00:24, 1 December 2014 (UTC)Reply

Syntax error edit

@Wrh2: would you mind changing the following line:

        -webkit-print-color-adjust: exact; //force printing on safari and chrome

to this:

        -webkit-print-color-adjust: exact; /* force printing on safari and chrome */

CSS only supports /* inline comments */, not // line comments. Thank you.

 – Minh Nguyễn 💬 00:07, 5 April 2015 (UTC)Reply

  Done -- WOSlinker (talk) 07:32, 5 April 2015 (UTC)Reply

img edit

Having this code:

img {
	max-width: 100%;
	height: auto;
	width: auto\9; /* ie8 */
}

The following ones are really necessary?

.topbanner img {
    max-width: 100%;
    height: auto;
    width: auto\9;
}

#mobileworld img {
 max-width: 100%;
 height: auto;
 width: auto\9; /* ie8 */
}
 
.banner-image img {
    max-width: 100%;
    height: auto;
    width: auto\9;
}

--Andyrom75 (talk) 18:51, 18 June 2015 (UTC)Reply

All four look unnecessary to me, but the last three should definitely be unneeded unless they are resetting an overridden property. I'd support removing at least the last three, possibly all four, and seeing if there are any resulting display issues on the main page. -- Ryan • (talk) • 19:15, 18 June 2015 (UTC)Reply
Currently ".banner-image img" & ".topbanner img" are necessary for the right rendering of {{banner}} & {{pagebanner}}, but the first CSS makes them redundants. To suppress them all (i.e. including the first), I suppose that some code in the above two templates must be rewritten. --Andyrom75 (talk) 10:09, 19 June 2015 (UTC)Reply

The img {} rule must be removed as soon as possible. Having such un-targeted CSS will result in unpredictable behaviour of future MediaWiki deploys. Please replace it with more selectively targeted rules or it will just be deleted. Thanks, ESanders (WMF) (talk) 14:19, 8 July 2016 (UTC)Reply

Very much agreed - the "img" rule has been removed. -- Ryan • (talk) • 15:20, 8 July 2016 (UTC)Reply

Could an admin please edit Common.css? edit

Swept in from the pub

Any admin, could you please copy the 4 lines at http://pagebanner.wmflabs.org/wiki/MediaWiki:Common.css into MediaWiki:Common.css so that {{PAGEBANNERS}} works with icons? Thanks a lot!

By the way, today is the last day of Sumit's Google Summer of Code! Congratulations to him for the hard work developing the banners extension :-) Syced (talk) 06:36, 18 August 2015 (UTC)Reply

Although the change looks very simple and safe, I still wouldn't be comfortable asking any admin to do this. The skills of an Admin are not actually for technical work.
I have background in HTML, but as far as I can tell, only Ryan has been actively editing CSS files on Wikivoyage. It would probably be best to ask him. --Andrewssi2 (talk) 07:30, 18 August 2015 (UTC)Reply
I've messed with this stuff before, so I went ahead and did it. Let me know if you find any problem... Texugo (talk) 11:26, 18 August 2015 (UTC)Reply

Tabs out of alignment edit

Swept in from the pub

The tabs at the top of the pages have gone out of alignment for me when I am viewing pages. The bottom line of the tabs drops down lower. They are fine when I am editing. It happens in 3 different browsers. Not a big deal - it seems just cosmetic. Is the same happening for other people? Nurg (talk) 07:21, 18 August 2015 (UTC)Reply

Yes. I've noticed exactly the same already yesterday afternoon (about 20 hours ago) on both Safari and Firefox. ϒpsilon (talk) 07:25, 18 August 2015 (UTC)Reply
I was having the same issues. I found it coincidental that the changes to MediaWiki:Common.css mentioned just above this thread were made in a similar timeframe. Upon reverting the changes, the tab alignment issue appears to have been fixed. Our coders will need to work to solve this bug before reimplementing the code into Common.css. I've also made the header of this thread a subset of the one before considering they're directly related. James Atalk 13:20, 18 August 2015 (UTC)Reply
Edit: Although the problem seemed to be have been fixed temporarily, as soon as I posted this message it returned, even after refreshing the cache. Not too sure in that case; if people don't think the changes are related, I'm happy for the changes to Common.css be readded. James Atalk 13:25, 18 August 2015 (UTC)Reply
The problem seems to be in the core Mediawiki stylesheets - it looks like a software update has a bug. Specifically, the height on this style rule seems to be problematic: div.vectorTabs li a. If the problem isn't resolved with the next update we can try to find a workaround. -- Ryan • (talk) • 15:07, 18 August 2015 (UTC)Reply
I'd assumed it was an issue with the new Pagebanner extension, but apparently not? I do note that the tabs are rendered correctly when the page is first loaded; the lines shift after a half second or so. Powers (talk) 00:55, 19 August 2015 (UTC)Reply
I've had a bit more time to compare Wikivoyage code to Wikipedia, and while that CSS is what's causing the tabs to enlarge, it's actually code from the listing editor that is the root cause of the problem. I'm not sure if something in Mediawiki changed recently that triggered this bug or if it's been there since the listing editor changes launched, but I'll try to figure out a fix as soon as possible. -- Ryan • (talk) • 01:30, 19 August 2015 (UTC)Reply
I think that this change will resolve the issue, but please revert it if it creates any problems with the listing editor. -- Ryan • (talk) • 01:38, 19 August 2015 (UTC)Reply
thanks. Nurg (talk) 06:37, 19 August 2015 (UTC)Reply

TOC strangeness edit

Swept in from the pub

Is someone changing Wikivoyage settings? The table of contents styling broke for all page banners using the old Template:Pagebanner due to the underlying HTML changing - the CSS class "tocFloat" stopped appearing on the div with id "toc", causing the TOC to render as a white block. In trying to fix the issue by modifying MediaWiki:Common.css I've seen the old HTML return and then disappear once or twice. Does anyone know what's going on? -- Ryan • (talk) • 02:01, 27 August 2015 (UTC)Reply

Might be due to seeing a cached version of the page, with the old banner combined with the new Common.css without the css for the old banner, but that's just a guess. -- WOSlinker (talk) 18:09, 30 August 2015 (UTC)Reply
This happened prior to deploying the new banner across the site, and it was actually the underlying TOC HTML (not CSS) that changed, so something else was going on. In any case, now that the full site has moved to the new banners it shouldn't make any difference, I just found it bizarre that core Mediawiki functionality (TOC generation) was suddenly changing. -- Ryan • (talk) • 18:27, 30 August 2015 (UTC)Reply

Table of contents (ToC) working at last! edit

Swept in from the pub

I just discovered that the ToC is finally being displayed with tertiary headings dropping down at Vancouver.

This is a major achievement since the eye-candy banners weakened the functionality of our site many months ago and I'd like to thank whoever is responsible. Who was it? 80.234.141.170 11:58, 26 August 2015 (UTC)Reply

Ooooooh! It gets better! Clickable quaternary headings are displayed if you hover your mouse over the relevant tertiary heading that drops down! Does this neat restoration require Java or anything fancy? 80.234.141.170 12:00, 26 August 2015 (UTC)Reply
No Java, only JavaScript CSS. Indeed, it is cool that we are now able to deep-link to for instance Vancouver>Get around>By car>Parking, very convenient when friends on social networks ask for travel tips. Syced (talk) 03:34, 27 August 2015 (UTC)Reply
Is it actually using Javascript? The TOC looks like it's primarily done with CSS, and if I disable Javascript in my browser it still seems to work. -- Ryan • (talk) • 03:48, 27 August 2015 (UTC)Reply
It's all CSS :-) You can thank User:Sumit.iitp a student in India for making that happen :-) Jdlrobson (talk) 18:10, 27 August 2015 (UTC)Reply

Remove preference "Add an [edit] link for the lead section of a page"? edit

Swept in from the pub

The gadget "Add an [edit] link for the lead section of a page" in Preferences does not look great at all with banners (details and screenshot).

Are there people using this preference? If not, should we remove it? If yes, could someone with rights do it? Syced (talk) 03:15, 31 August 2015 (UTC)Reply

Wait, this is great. It didn't work before, and now it does. Any logged-in users who don't like it can just turn it off in their Preferences, right? Finally now we have the option of editing only the lead section, which is really useful on big articles. I have been waiting for this since Dec 2013 - see Wikivoyage:Travellers' pub/2013 (additional)#Editing only the lead section. If it can be made prettier, then great, but don't remove it please. Nurg (talk) 06:36, 31 August 2015 (UTC)Reply
I agree. This is a very handy feature. Pashley (talk) 11:59, 31 August 2015 (UTC)Reply
Happy to see that it is useful to some editors. But it really defaces banners so I would rather have it turned off by default even for logged-in users, which I believe is the case now? Cheers! Syced (talk) 13:51, 31 August 2015 (UTC)Reply
I presume it is correct that it is turned off by default, and that only those of us who have turned it on will see it. That's fine. Nurg (talk) 09:56, 1 September 2015 (UTC)Reply
Good to see it's working, but it's not an ideal implementation. Is it possible to change the text colour to be white at least? If it's complicated, I wouldn't bother though. James Atalk 06:23, 1 September 2015 (UTC)Reply
For anyone interested in experimenting with updated styles on the banner edit links, the following CSS can be added to your userspace common.css file and should change the font color to white:
.wpb-topbanner span.mw-editsection a {
    color: white;
}
-- Ryan • (talk) • 06:28, 1 September 2015 (UTC)Reply

class "prettytable" in mediawiki:common.css edit

Swept in from the pub

There seems to be a class="prettytable" defined in w:mediawiki:common.css (and on other wikis, such as fr:mediawiki:common.css), which is missing from mediawiki:common.css here. That's affecting formatting of tables imported from another wiki, like the distance chart on Amqui (which was imported from user:Amqui's fr:Amqui guide article). K7L (talk) 18:20, 13 September 2015 (UTC)Reply

I've set it to wikitable, which provides it with some borders now. -- WOSlinker (talk) 20:12, 14 September 2015 (UTC)Reply

Minor code change edit

For code optimization a to remove an alert, this code:

.oo-ui-icon-dotm {
     background-image: url('https://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Yes_Check_Circle.svg/25px-Yes_Check_Circle.svg.png');
}
.oo-ui-icon-otbp {
     background-image: url('https://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Yes_Check_Circle.svg/25px-Yes_Check_Circle.svg.png');
}

should be changed with:

.oo-ui-icon-dotm, .oo-ui-icon-otbp {
     background-image: url('https://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Yes_Check_Circle.svg/25px-Yes_Check_Circle.svg.png');
}

--Andyrom75 (talk) 14:16, 9 September 2016 (UTC)Reply

  Done -- WOSlinker (talk) 23:29, 9 September 2016 (UTC)Reply

hlist class removal edit

After the installation of the pagebanner extension, the hlist class should be useless hence should be removed. --Andyrom75 (talk) 12:13, 3 November 2016 (UTC)Reply

It is currently used in Template:Flatlist which is in turn used in Template:Warningbox. -- WOSlinker (talk) 13:27, 3 November 2016 (UTC)Reply
I've updated Flatlist to use template styles at Template:Flatlist/style.css, so will see about removal soon. -- WOSlinker (talk) 21:11, 4 August 2021 (UTC)Reply

{{Bottomboxes}} edit

has been converted to responsive design and redone with templatestyles. Accordingly, the rules with .main-page-bottom-box no longer apply anywhere and can be removed. @WOSlinker: ARR8 (talk | contribs) 20:13, 17 February 2019 (UTC)Reply

Done -- WOSlinker (talk) 13:17, 18 February 2019 (UTC)Reply
@WOSlinker: Thanks. Could you also take out the rules beginning with .banner, which I've now copied over to {{Banner}}? ARR8 (talk | contribs) 19:24, 18 February 2019 (UTC)Reply
Done -- WOSlinker (talk) 22:27, 18 February 2019 (UTC)Reply

archive-box removal edit

I'm planning on removing the archive-box code soon as it's not used anywhere. -- WOSlinker (talk) 16:53, 13 July 2019 (UTC)Reply

Using Templatestyles edit

I'm going to look at moving a few sections of the code out of this page into subpages, and use the templatestyles tag. I'll be mainly looking at the code used by Template:Sleeppricerange, Template:Eatpricerange, Template:Routebox and Template:Climate. The main advantages are that any admins or templateeditors can then update it rather than relying on someone with the interfaceadmin role. -- WOSlinker (talk) 09:58, 12 December 2020 (UTC)Reply

Return to "Common.css" page.