MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

238px widths

Here, the 238px widths specified in Common.css (e.g. for mbox-small, mbox-small-left, etc) appear close to but not exactly the same as the 22.0em default width used for {{Sidebar}}s, {{Infobox}}es, etc. Can they be tweaked accordingly, or is this just a coincidence resulting from e.g. the zoom setting (the default 100%, I think) in the Firefox-based browser I'm using? Sardanaphalus (talk) 09:06, 28 June 2014 (UTC)

q - curly quotes

I just noticed that <q> is now whitelisted by Sanitizer.php:

Markup	Renders as
<q>HyperText Markup Language</q>	HyperText Markup Language

But it uses curly quotes, which are recommended against per MOS:QUOTEMARKS. Should we add CSS to change the style? --  Gadget850 ^talk 20:38, 9 July 2014 (UTC)

I believe that <q> was whitelisted as a side-effect of https://gerrit.wikimedia.org/r/72981 (which also fixed its nesting behavior). However, I do not believe that the CSS styling is wrong. MOS:QUOTEMARKS just refers to how the quotation marks are represented in wikitext. One could make a strong argument that the function of CSS is precisely to handle presentation aspects like that. (That said, the gratuitous use of <q> instead of quotation marks also runs contrary to some recommendations in MOS:QUOTEMARKS, since the quotation marks will not exist in the HTML source.) C. Scott Ananian (talk) 20:55, 9 July 2014 (UTC)

Should this element be used in some of the quotation templates? Helder.wiki 21:16, 9 July 2014 (UTC)

There's something a bit odd going on here. The text inside <q>...</q> above is rendered in straight double quotes in Opera, but curly double quotes in Chrome, Firefox and IE11. I suspect that the user agents may have different interpretations of q::before {content: open-quote;}.

As an aside, the browsers display the plain html <q>...</q> content (outside of Wikipedia) as curly double quotes (Firefox), straight double quotes (Chrome, Opera) or single curly quotes (IE11)!

I'd say there is a case for an entry in common.css using whatever agreed characters (e.g. ") for q::before and q::after just to regularise what our readers see regardless of browser. --RexxS (talk) 21:54, 9 July 2014 (UTC)

<q> was whitelisted with MediaWiki 1.22/wmf9 on July 11, 2013. --  Gadget850 ^talk 01:50, 10 July 2014 (UTC)

<q> is for inline quotes and I don't see any templates for that. --  Gadget850 ^talk 01:54, 10 July 2014 (UTC)

Template:Tq is for inline quotes (and elsewhere), but there's little value in attempting to incorporate <q>...</q> just for the semantics. --RexxS (talk) 14:54, 10 July 2014 (UTC)

I've gone ahead and added the CSS to show regular quote marks. -- [[User:Edokter]] {{talk}} 08:42, 25 July 2014 (UTC)

Protected edit request on 24 July 2014

Please change:

div#mw-protect-cascadeon {

to:

div#mw-protect-cascadeon,
div.titleblacklist-warning {

Jackmcbarn (talk) 18:30, 24 July 2014 (UTC)

 Done Legoktm (talk) 02:21, 25 July 2014 (UTC)

Double border

When <code>...</code> encloses <pre>...</pre> (which is pointless because they both produce monospace), the effect is dreadful: see Template talk:Geobox#Mountains and ranges. There's a related problem with {{pre}}, see Template talk:Pre#Double border. --Redrose64 (talk) 09:09, 1 August 2014 (UTC)

It is just as bad if the formatted text wraps.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. --  Gadget850 ^talk 09:58, 1 August 2014 (UTC)

print.css add a logo and version number

Hi all, I try to modify the print.css to include a logo on the header of each pages along with a version number of the document (the last modified date of the article would be enough) I managed to change my margins, titles colour, page breaks but nothing else...

I tried many combinations and went on a lot of websites to no avail.

Can anyone point me to a tutorial/example of a print.css for mediawiki?

Is there a list of items I can access from the .css on my wiki? (e.g.: .lastUpdated )?

Thanks, Alex — Preceding unsigned comment added by 31.55.62.113 (talk) 08:49, 3 August 2014 (UTC)

Changing the appearance of hlist

It has come to my attention that there are editors out there who who think pipe-separated lists are easier to read than bullets. it turns out, there is a solution. all you have to do is open your personal common.css, and add the following lines

.hlist dd:after,
.hlist li:after {
    content: " | ";
    font-weight: normal;
}

and all the hlists will be rendered with pipes for the separators instead of the dots. it is also possible to change them to something else, even your favorite image on commons. I am posting this tip here in a centralized forum, since this has come up many times before. Frietjes (talk) 15:50, 11 August 2014 (UTC)

And of course, if you only want commas as your list separators, then .hlist dd:after, .hlist li:after {content: ", ";} will do the trick for you. --RexxS (talk) 20:18, 11 August 2014 (UTC)

I proposed hlist subclasses here some time ago to allow customization of the hlist separator (see MediaWiki talk:Common.css/Archive 15#hcomma, though note that the Yu-Gi-Oh! Wikia's live CSS now differs from the sample code I posted directly in the discussion); at the time, Edokter was receptive but hesitant because he wasn't sure there was actually demand for them. This demonstrates that there could potentially be such demand, though I'll be the first to admit that trying to extrapolate a pattern from a single data point is a fool's errand. Regardless, as I did when I posted that topic, I would personally like to see these classes added to the "canon" hlist CSS. 「ディノ奴やつ千せん？！」^{? · ☎ Dinoguy1000} 01:16, 9 September 2014 (UTC)

Classes for vertical-align top in tables? Why not?

Hello,

I found that in pt.wikipedia there is no way to top or bottom align cells/rows content without adding the css inline in every cell/row, is the same here?, how this is done here in e.wikipedia?! I'm suggesting there to add 2 classes in Commons.css as follow:

/* 
 - 10/9/2014 - 
*/

.vat, .vat tr, .vat td {vertical-align:top}      /*  top   */
.vab, .vab tr, .vab td {vertical-align:bottom}   /*  bottom  */

What do you think of this? Dianakc (talk) 00:54, 11 September 2014 (UTC)

So instead of writing style="vertical-align:top;" on each table row, we could write class="vat" on each table row? I would have thought that it just made the markup less understandable for no real gain, or am I missing something? --RexxS (talk) 01:09, 11 September 2014 (UTC)

It is not really for specific rows, columns or cells, but for whole tables, in large tables the class can save some bytes and code clutter. If you are using class="wikitable" but want to set a vertical align to the whole table, you will just need to use class="wikitable vat". For specific cells, columns or rows, the class or the inline will do, this won't change. I found this issue when an user asked me how to align all the table content at the top then he said Wow! I have to add the style/valign to every row.Dianakc (talk) 02:38, 11 September 2014 (UTC)

Ah - for the whole table, I can see there's a genuine advantage, as the inline style= definition doesn't work on a whole table. Saving bytes isn't really a consideration, but I'd happily support it for reducing code clutter. --RexxS (talk) 14:57, 11 September 2014 (UTC)

That's it :) I'm concerned that sometimes we get a lot of code for things that a simple class could do. I'm suggesting this code for pt.wikipedia, but feel free to use/adapt and suggest it here as well. Maybe we can use more self-explanatory names for the classes such .v_align_top and .v_align_bottom etc. Dianakc (talk) 19:27, 11 September 2014 (UTC)

Shouldn't the class names describe the content instead of the style we will apply to that content, for better semantics? What kind of table/data will be aligned to the top of cells and what will be keept with the default alignment? Helder 11:41, 21 September 2014 (UTC)

@Jdlrobson: comments on this? Helder 11:41, 21 September 2014 (UTC)

What Helder says. Classes should be semantic and explain concepts rather than be shortcuts for CSS rules. We should do an audit of all tables and identify which ones are better vertically aligned. Out of interest are there any tables you would not want to be vertically aligned? we might decide we need a new class name for this one rule but by using a more useful name we make changes to these types of table easier in future. Even better you might not need an additional class at all :) Jdlrobson (talk) 17:34, 21 September 2014 (UTC)

No common.css in 1.23.3: how to make infoboxes float to the right?

There's no common.css in v.1.23.3, and .less files seem to provide no means for enforcing the site-wide infobox float to the right. Any hints? 167.88.112.200 (talk) 01:10, 21 September 2014 (UTC)

Proposal to add veonly class

I propose that we add a veonly class to common.css like I did at testwiki:Special:Diff/217226. This will allow us to only show certain text to users with VisualEditor enabled. I plan to use this on Template:No article text to add a link to start a new article via VE, but only for users that have it enabled in their preferences (discussion about that is at Template talk:No article text#Include visual editor). Are there any objections? Jackmcbarn (talk) 14:43, 8 October 2014 (UTC)

I would suggest the class name ve-show, to match sysop-show et al., unless there's some compelling reason to prefer veonly. 「ディノ奴やつ千せん？！」^{? · ☎ Dinoguy1000} 21:50, 9 October 2014 (UTC)

@Dinoguy1000: VisualEditor uses "ve-" names internally, so I'd rather not use that particular name, but I would be open to another alternative. Perhaps veshow? Jackmcbarn (talk) 23:05, 9 October 2014 (UTC)