MediaWiki talk:Common.css

Why not update it to be in style of "article header" at minecraft forums?

background: url(http://static.minecraftforum.net//public/style_images/mcf/skin/bg-article-header.png) repeat;
border: 2px solid #C2D2DF;
padding: .7em 10px;
color: white;

– xPaw at 11:24, 29 April 2012 (UTC)

Because it looks really bad, and also the header style ties in with the logo. –ultradude25 ^(T|C) at 13:13, 29 April 2012 (UTC)

Can the following code:

div.atflb {
 width: auto !important
}

be changed to include the bottom advert as well:

div.atflb, div.btflb {
 width: auto !important
}

Thanks BryghtShadow 15:34, 9 May 2012 (UTC)

Infobox common is far too wide, it looks frankly rediculous on every page I've seen. I'm not sure if it's because members aren't on the same width or if it's just all-round poor judgement but I would suggest changing it. --86.16.72.219 20:10, 23 November 2012 (UTC)

I've adjusted the width back to its original 300px. I also removed a little bit of space between the right margin and the content. -- Hower64 07:58, 4 December 2012 (UTC)

Please remove Liberation Sans font. It looks terrible. IllidanS4 (talk • contribs • logs) 11:20, 7 December 2013 (UTC)

Not going to happen. It's there because it has the same metrics as Arial and is likely to be found on computers that don't have Arial or Helvetica. Even if technical requirements weren't an issue, "looks terrible" is a very weak and subjective argument. -- Orthotope^talk 11:57, 7 December 2013 (UTC)

Even if we were to remove it (which would go back to having inconsistent font width on Linux and probably Mac), it would just come back as a default part of mediawiki as they have recently been working on a Typography Update (which I assume will be released in 1.23 or 1.24) that has Liberation Sans as part of its stack. We could maybe change the order to make Arial come before Liberation Sans, however I didn't do that as Arial didn't seem to render as well as Liberation Sans on Linux systems that have it installed, but looks just about as good as Arial on Windows. You can always change your own CSS or your browser settings if a slightly different looking font is really that terrible.

Also you signature is a bit excessive, and contains wikicode which should be substed (mainly that if statement and the pointless urlencodes). –Matt ᐸ Talk
Contribs ⎜ 13:05, 7 December 2013 (UTC)

This looks more like a significant than slight difference to me. Liberation is far worse readable than Arial and the letters look quite distorted. You may at least change the order (as said - fallback when Arial is not found), as it is in the Typography Update (considering Arial 'better' than Liberation). IllidanS4 (talk • contribs • logs) 23:24, 8 December 2013 (UTC)

That's not an issue with the font, your browser is rendering it incorrectly. Check your clearfont or truetype settings. This is what it's supposed to look like (Arial on top, Liberation Sans on bottom). —Kanegasi ☺C 23:51, 8 December 2013 (UTC)

Is there a way to set table cell alignment per-column, apart from setting it cell-by-cell in a cumbersome way?

If not, could we do a solution like the following: (found at http://stackoverflow.com/questions/24494604/mediawiki-table-efficiently-applying-different-alignment-for-different-column):

Add these rules:

table.col-1-center td:nth-child(1) { text-align: center; }
table.col-2-center td:nth-child(2) { text-align: center; }
table.col-3-center td:nth-child(3) { text-align: center; }
...
table.col-3-center td:nth-child(n) { text-align: center; }

table.col-1-right td:nth-child(1) { text-align: right; }
table.col-2-right td:nth-child(2) { text-align: right; }
table.col-3-right td:nth-child(3) { text-align: right; }
...
table.col-9-right td:nth-child(n) { text-align: right; }

Use it like so:

{| class="wikitable col-3-right col-4-right"
! Account Number !! Account Name !! Source Balance !! Target Balance
|-
| 1234 || UK Savings || 402.00 || 323.21
|-
| 5432 || Car Fund || 12,943.00 || 23,433.21
|-
| 6789 || Other Expenses || 4.21 || 6.21
|}

– Sealbudsman ^talk/_contr 21:45, 13 January 2017 (UTC)

👁 Image
 Support I could see this being used in {{ :Renewable resource/table}}. It would probably be good for other tables as well. Majr and Orthotope, can you both participate in this discussion? The Blobs^{👁 Image}
14:50, 14 January 2017 (UTC)

A better way of implementing this might be to use a -data-* custom attribute in the topmost cell of a column, and have some JS search for such attributes and apply the styles in them to the whole column. This would allow any CSS to be applied to table columns, not just whatever CSS was decided should have its own class, and would thus prevent a potential proliferation of such classes. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 16:49, 14 January 2017 (UTC)

👁 Image
 Support The Blobs^{👁 Image}
17:03, 14 January 2017 (UTC)

👁 Image
 Interesting, can you give a code example of a table using that custom attribute? – Sealbudsman ^talk/_contr 20:05, 14 January 2017 (UTC)

To use your first example:

{| class="wikitable"
! Account Number !! Account Name !! -data-col-style="text-align: right;" | Source Balance !! -data-col-style="text-align: right;" | Target Balance
|-
| 1234 || UK Savings || 402.00 || 323.21
|-
| 5432 || Car Fund || 12,943.00 || 23,433.21
|-
| 6789 || Other Expenses || 4.21 || 6.21
|}

Obviously, the name -data-col-style could be changed for a different one if desired. In addition, having a class on tables using this feature might make the JS more efficient, by allowing it to search only for that class instead of having to check all tables for any data attributes. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 21:17, 14 January 2017 (UTC)

While the versatility of that is nice, setting styles with JS is very much undesirable. So I'll just add the alignment styles, since that's all we'd probably ever use anyway. –Majr ᐸ Talk
Contribs 11:43, 16 January 2017 (UTC)

I notice the where we've put .mw-userlink[title="User:Minecraft_Staff"], it uses an underscore, and the flair doesn't seem to be working, whereas other names that use spaces like "Jeb mojang" do have the flair. I bet it needs a plain space.

Also, flair is given to .mw-userlink[title^="User:Mojang tommo"], where ^= is a selector for "starts with". Probably should be the equals sign, right? – Sealbudsman ^talk/_contr 03:34, 20 April 2017 (UTC)

Dinoguy1000, a weird formatting issue with the navboxes was mentioned on the community portal some time ago: Weird list formatting in Navboxes, and I've figured out the cause of this. Could you maybe replace the statement margin-right: -0.313em; with the statement margin-left: 0.313em; at the selector .hlist li > ul li:last-child:after? That should do it nicely, thanks – Jack McKalling [ 👁 Jack McKalling's User page
👁 Jack McKalling's Talk page
👁 Jack McKalling's Contributions
] 00:06, 7 December 2017 (UTC)

👁 Image
 Done, let me know if something breaks or it's not fixed or whatever. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:46, 7 December 2017 (UTC)

The CSS selector that hides levels of the TOC when using {{TOC|limit=}} or {{TOC limit}}, prevents you from hiding down from just level 3, as it would also hide level 2:

/* Allow parts of toc to be hidden */
/* Section levels */
.toc-hidelevel2.toclevel-1ul,
.toc-hidelevel3.toclevel-2ul,
.toc-hidelevel4.toclevel-2ul,
/* Numbers */
.toc-nonumbers.tocnumber{
display:none;
}

I suggest to fix this by changing the second mention of .toclevel-2 ul to .toclevel-3 ul. I wonder if there was any specific reason for this, or if it's just an overlook. Thanks in advance. – Jack McKalling [ 👁 Talk
👁 Contrib
] 09:46, 27 September 2018 (UTC)

👁 Image
 Done Fixed by Majr. – Jack McKalling [ 👁 Talk
👁 Contrib
] 11:13, 27 September 2018 (UTC)

Also checked all whatlinksheres of both templates, and no page uses limit=4, so all is done. – Jack McKalling [ 👁 Talk
👁 Contrib
] 11:37, 27 September 2018 (UTC)

Add this:

/* Hatnotes and disambiguation notices */
.hatnote{
font-style:italic;
}
.hatnotei{
font-style:normal;
}
div.hatnote{
/* @noflip */
padding-left:1.6em;
margin-bottom:0.5em;
}
div.hatnote+div.hatnote{
margin-top:-0.5em;
}

Fadyblok240 (talk) 12:29, 14 September 2020 (UTC)

Why? What does this CSS change, and why is it better than what we have right now? We are not in the habbit of random CSS changes for no reason. –KnightMiner ^t/_c 15:24, 15 September 2020 (UTC)

It reduces line spacing between hatnotes and enables cancellation of italics within hatnotes. Also you should remove the styling for dablink and copy the contents of {{hatnote/sandbox}} to replace the contents of {{hatnote}}.Fadyblok240 (talk) 00:07, 16 September 2020 (UTC)

The sound icons are black by default (example: Wood§Sounds), which makes it easy to see on light theme, but that is not the case on dark theme.

We can easily make it white by using the CSS invert filter for the dark theme, like so:

.theme-fandomdesktop-dark.sound-title::after{
filter:invert(1);
}

This can also be used for other icons which you may want to be white on dark theme (or vice versa with the light theme). You can make an utility class, and then add it to the image like this [[File:Example.jpg|class=class-name]]. That way, for example, if you want a black icon such as SlotSprites to be white, you make a utility class (or use the ones already in use for that particular case, such as .sprite:

.theme-fandomdesktop-dark.darklight-img{
/*
 * Making it 87% rather than 100% white so people with astigmatism can also see
 * it better too.
 */
filter:invert(.87);
}

And then add it into the image:

[[File:Example.jpg|class=darklight-img]]

That way these icons will be way easier to see on dark theme, specially for partially blind people. Alternatively, if you want to use any other color than white/shades of gray, there is a tool for that.

Greetings.

Polymeric 20:43, 26 November 2021 (UTC)

This discussion has been moved from MediaWiki talk:Fandomdesktop.css. —⁠andrybak (talk) 00:15, 24 December 2021 (UTC)

Screenshot to demonstrate the issue: [1]. For the highlighted ref, the text color is defined via theme variable:

.page{
color:var(--theme-page-text-color);
[...]
}

... which is good. The background color is hard coded:

ol.referencesli:target,
sup.reference:target,
span.citation:target{
background-color:#C1DAF2
}

... which is not so good. Disabling background-color:#C1DAF2 makes background color fallback to the default CSS:

ol.referencesli:target,sup.reference:target{
background-color:rgba(var(--theme-link-color--rgb),.2);
}

... which gives good contrast: [2]. I think it might be better to remove the custom rule for background-color:#C1DAF2 or replace it with a different highlight, e.g. a border or underline. —⁠andrybak (talk) 23:45, 23 December 2021 (UTC)

Hmm, I double checked and I can't actually find out where background-color:#C1DAF2 is coming from. I just assumed that it was MediaWiki:Fandomdesktop.css or another CSS page in the MediaWiki namespace, because I was crossreferencing this behavior with two other wikis, which just have the rule with background-color: rgba(var(--theme-link-color--rgb),.2);. —⁠andrybak (talk) 00:10, 24 December 2021 (UTC)

Ah, found it! It is actually in MediaWiki:Common.css. I'm not sure why the search for C1DAF2 didn't give the correct page. —⁠andrybak (talk) 00:15, 24 December 2021 (UTC)

I just realized that in light mode, #C1DAF2 and rgba(var(--theme-link-color--rgb),.2) produce the same color. This raises the question: why is the hardcoded color needed in the first place? —⁠andrybak (talk) 00:22, 24 December 2021 (UTC)

The rule was added long before we had a dark mode. I changed the background color to use the variable. MarkusRost (talk) 09:49, 24 December 2021 (UTC)

@Admins, have you considered moving the CSS code from Common.css to TemplateStyles? English Wikipedia is currently in the endless process of conversion, quote:

These are being converted to TemplateStyles for multiple reasons:

1. To allow ordinary users and administrators to change "sitewide" styles.
2. To decrease the page load on all pages.
3. To return power to style mobile to local editors.

The linked page has more details. If this is something you're interested in, it would be better to do it sooner rather than later to avoid accumulation of technical debt. —⁠andrybak (talk) 19:40, 5 October 2023 (UTC)

User:Magiczocker, what do you think about this suggestion? —⁠andrybak (talk) 11:32, 8 October 2023 (UTC)

I support the change and could remove styles from MediaWiki:Gadget-site-styles.css, MediaWiki:Common.css and MediaWiki:Mobile.css after someone made these changes. Keep in mind that templates like Template:Table choice can't be converted. – Magiczocker (talk) 15:11, 9 October 2023 (UTC)

Regarding Template:Table choice, English Wikipedia uses inline CSS for such templates. See wikipedia:Category:Unified table cell templates. —⁠andrybak (talk) 16:34, 11 October 2023 (UTC)

This was briefly discussed in Discord (link), and according to our server host Weird Gloop, if you want to decrease page load times, it usually only makes sense to use TemplateStyles if you have many different templates and Common.css gets too large to get delivered on each page load, which is definitely the case for Wikipedia but not for us. It might still make sense for the other reasons though, but I'm personally not convinced with making the styling for the wiki less centralized and thus harder to maintain. To my knowledge, the general sentiment is that we want to actually move away from TemplateStyles for the few templates where it's currently used, though I don't recall any specific reasons for why exactly that is. | violine1101 ^(talk) 16:28, 15 October 2023 (UTC)

I would like to suggest the following change be made:

Before: font-family: "Liberation Sans", Arial, Helvetica, FreeSans, sans-serif; After: font-family: FreeSans, "Nimbus Sans L", "Liberation Sans", Arimo, Helvetica, Arial, sans-serif;

This would fix the "liberation sans is ugly" issue and also improve the look on some linux systems. "Nimbus Sans L" is a fork of FreeSans and Arimo is a fork of Liberation Sans 161.230.153.71 20:10, 12 February 2024 (UTC)

Can you please add body { font-family: serif; } into the page for a more encyclopedic typeface? Thank you.--143.44.165.91 13:12, 8 April 2024 (UTC)

No, that won't be added as it's not a specific font but just a browser/device default font. Additionally using a serif font is heavily opposed in MCW:Forum/New typeface. -- 👁 Image
MarkusRost (talk) 13:25, 8 April 2024 (UTC)

Transcluded from MCW:Admin noticeboard#MinecraftTen font. Note: This is the proper place for it. My bad.

I uploaded a file from the minecraft.net files (File:MinecraftTen.woff, the Minecraft Ten font) and was wondering, while looking at MediaWiki:Common.css, if it could be added there. If you feel that the file could have "malicious code," (as the file page says) then feel free to delete the file. I did a test with my signature, at File:Signature with MCTen font.png. 👁 Image
(talk|edits) 22:18, 7 December 2024 (UTC)

Now as templatestyles have existed for a while, keeping all template-specific styles in a sitewide stylesheet is unnecessary. Fatya (talk) 18:09, 5 August 2025 (UTC)

For a wiki of our size generally the drawbacks of templatestyles outweigh the benefits. Templatestyles causes CSS to be inline, which means it cannot be cached independently of the page text. This causes additional load for all page views. Keeping the commonly used styles in common.css lets it be cached by a users browser after the first page view and reused for subsequent views. Mudscape 👁 Image
talk 18:14, 5 August 2025 (UTC)

Specifying everything in a sitewide stylesheet wastes way more bandwidth than the inability to cache inline CSS produced by templatestyles. While, for example, Template:Navbox is used everywhere, something like Template:LoadBox is used on only 64 pages, but its CSS is still being included on every single page, regardless of whether it's used or not. Fatya (talk) 18:33, 5 August 2025 (UTC)

That is certainly a candidate to move to a templatestyle, but the benefit is extremely small, and spreading out styles to multiple files increases the effort required to maintain the site css. So far its not something that is worth the effort to do. Mudscape 👁 Image
talk 18:39, 5 August 2025 (UTC)