MediaWiki talk:Common.css/Archive 17

Are we defining anywhere exactly what this class is for and what should typically be done with it; where it should always be used, never used, and optionally used? It seems difficult to generalize from the uses of it that I'm finding, other than it suggests "not the primary content" or something like that. It's not equivalent to unprintworthy, that being separate. I'm not sure if it's meant to be "also not printworthy as well as [some other constraint or lack of constraint]", or totally independent of that kind of analysis. It seems to be used by some hatnote-type things, but is not a part of their default code from Module:Hatnote.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:00, 10 September 2015 (UTC)

boilerplate is an old class that was used by some messaging templates in the pre mbox times. As far as I'm aware, we have no active defined use for it other than 'legacy' —TheDJ (talk • contribs) 17:10, 12 September 2015 (UTC)

Before anyone goes crazy removing it from templates, though, do note doing so will break some of AnomieBOT's regexes for TFD, FFD, PUI, deletion sorting, and {{

old AfD multi}} tagging of new articles. So let me know first what exactly you're planning on changing if you intend to do so. Anomie⚔

19:20, 12 September 2015 (UTC)

Yes, as always.. please don't brazenly remove classes, because wether it's intentional or not, there is probably a lot of stuff still depending on something like that. Usually when you remove a class, make damn sure that there is a proper replacement with either a semantic or a style intent. —TheDJ (talk • contribs) 20:19, 14 September 2015 (UTC)

See Template talk:Commons category#Mobile visibility? - the rule is not in MediaWiki:Mobile.css. Where is it, and where should it be discussed? --Redrose64 (talk) 22:59, 13 October 2015 (UTC)

These links seem relevant: [6], [7], phab:T107485, mw:Wikimedia mobile engineering#Get involved. PrimeHunter (talk) 00:15, 14 October 2015 (UTC)

There's a proposal at Template talk:Navbar to make navbars more accessible by using <abbr> tags instead of <span> tags. This would also involve a change to Common.css. Before we go through with this, could people check the CSS proposed at the edit request to make sure it's ok? — Mr. Stradivarius ^{♪ talk ♪} 14:24, 18 October 2015 (UTC)

Hi why not change

list-style-image: url(/w/skins/Vector/images/bullet-icon.png)

to

list-style-image: /* @embed */ url(/w/skins/Vector/images/bullet-icon.svg);
/* Fallback to PNG bullet for IE 8 and below using CSS hack */
list-style-image: /* @embed */ url(/w/skins/Vector/images/bullet-icon.png)\9;

Which allows bullet icon to show svg on supported browsers and png on not supported browsers.

That is LESS syntax, shich is not supported in site CSS (yet). -- [[User:Edokter]] {{talk}} 13:26, 27 September 2015 (UTC)

I used the old syntax. -- [[User:Edokter]] {{talk}} 13:39, 27 September 2015 (UTC)

@Paladox2017: What does e(...) do?

@Edokter: In this edit, what does the \9 do? --Redrose64 (talk) 18:10, 27 September 2015 (UTC)

@Redrose64: In LESS, e() means to escape any passed text, or to pass CSS literally that LESS does not recognize (it trips over \9). The \9 is a hack to make the line parse only under IE9 and below, while being ignored by everything else. -- [[User:Edokter]] {{talk}} 18:19, 27 September 2015 (UTC)

Well currently svg with png fallback is not supported in list-style-image so a workaround is to only show the png image in internet explorer 8 or lower since chrome is supported on old windows os and is supported on phones too. I am not sure what e does I copied the syntax from background-image and had help from @Edokter to make the syntax for list-style-image work. Paladox (talk) 18:57, 21 October 2015 (UTC)

The Unicode class (not sure where that is in the CSS cascade; I don't see it in w:en:MediaWiki:Common.css itself) is having the probably undesirable effect of forcing line-nonbreakability upon anything spanned by the class, including most spacing characters that are explicitly defined as line-break points. Simple test (resize your window horizontally to test):

• Bare   test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism
• {{Unicode|&thinsp}} template test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

Weirdly, it does not do this with all break-point characters, e.g.   (the normal space character):

• {{Unicode| }} template test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

I haven't the patience to put this through a zillion character tests to see which ones it's misbehaving with.

One consequence of this problem is that anything spanned by {{

• Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

except where it contains something else breakable, like a regular space character, a manually added thin-space, or a dash (i.e., most of them are probably quite visible):

• Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilistic—expialidocious Antidisestablishmentarianism

Fortunately, the zero-width space (​) does work for this purpose, when inserted "bare" (in this case, where the dash was):

• Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilistic​expialidocious Antidisestablishmentarianism
• But not inside {{unicode}}: Pneumonoultramicroscopicsilicovolcanoconiosis​Supercalifragilisticexpialidocious​Antidisestablishmentarianism

The super-freaky part is that in both the — and ​ examples that did break intentionally in the middle of Super...cious, the line will not break between Super...cious and Anti...ism, but if you narrow the page enough, suddenly it will break between Pneumo...sis and Super...cious, whereas the example immediately above them, which is identical other than not containing — or ​ (in a position inside Super...cious, unrelated to the Pneumo...sis and Super...cious boundary) will not break between any of the three words. Maybe that little WTF? is browser-dependent (I was testing this in Chromium as I wrote it, and just got identical results in Safari and Opera after saving it).

The non-breaking effect is sometimes desirable, as when {{

• ( Pneumonoultramicroscopicsilicovolcanoconiosis )

which would look stupid as

• (
   Pneumonoultramicroscopicsilicovolcanoconiosis 
  )

which actually happens at a narrow window width in Firefox!

I was going to add a |nowrap=y parameter to ensure it could be made unwrappable, when I discovered that it is almost always non-wrappable already, seemingly by accident (in Chrom*, Opera, and Safari).

PS: I found mention of this class in some scripts, in a function called mw.util.addCSS, which in turn is used by mw.loader.implement; it reads:

       mw.util.addCSS('.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + '.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ');

but this doesn't appear to do anything that would cause this line-break issue.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:20, 19 October 2015 (UTC)

I think I narrowed down the problem. (Using Chromium on Linux but getting the same results as what you report for Chrom* on Mac.) Removing the unicode class from the container spans, i.e. from <span class="unicode">&thinsp;</span> to <span>&thinsp;</span>, still results in Chromium treating the thinsp as non-breaking. Matt Fitzpatrick (talk) 10:35, 20 October 2015 (UTC)

Yeah, this appears to be the spans, not the class. For example:

Bare thin-spaces, with the whole string wrapped in the Unicode class:

Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

Thin-spaces wrapped with unclassed spans:

Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

It's the span-wrappers that are causing the behaviour. {{Nihiltres |talk |edits}} 20:43, 21 October 2015 (UTC)

Interesting. This will bear some deeper testing, as it may have some implications for various templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:15, 25 October 2015 (UTC)

Yes it's the spans. or rather, it is the fact that adjoining characters can have extra meaning, and by using the spans, you add yet some extra meaning, effecting the linebreaking logic. Short story: Just DONT do this, it cannot work. If your browser is dumb enough not to support thinsp properly, then u should get a better browser or OS, not work around it by wrapping it with something that might force a font, that MIGHT save u, or not. Adding hacks like {{

thinsp}} for such crappy old browsers can have side effects and you just found one. That's why I don't favor such kind of hacks. —TheDJ (talk • contribs

) 21:18, 21 October 2015 (UTC)

I'm having difficulty following the point of that half-rant. A behavior exhibited by a large number of browsers is not "dumb" behavior by one "crappy old browser". I have no old browsers on any of my systems (except in virtual machines for testing during development). {{

snd}}, providing a wiki-syntax-familiar alternative to raw HTML code for editors who's learned the former but not the latter.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:15, 25 October 2015 (UTC)

div.redirectMsg a.mw-redirect:after {
  content: ' <double redirect>';
  color: #000;
  font-style: italic;
}

CSS to warn users from creating double redirects. — Dispenser 23:39, 15 November 2015 (UTC)

Is there a way to control the style of the printed version in my

I think that is controlled by the printer driver or browser, not our print stylesheet. -- [[User:Edokter]] {{talk}} 15:37, 2 January 2016 (UTC)

Yes you can, I do it at meta:User:Redrose64/monobook.css --Redrose64 (talk) 21:11, 2 January 2016 (UTC)

I'm afraid that does not affect the header and footer as outlined by Mahmudmasri. -- [[User:Edokter]] {{talk}} 21:14, 2 January 2016 (UTC)

Thanks

talk

) 13:08, 3 January 2016 (UTC)

I suggest adding another class that works like plainrowheaders but does not left-align the text. This could be useful where centering is desired but bolding is not, as the plainrowheaders style overrides the table's alignment, so you can't just set style="text-align: center" on the table to center the headers, you have to do it on each header individually.

In order to retain backwards-compatibility, this needs to be a separate class – I don't expect anyone to go over thousands of articles to replace class="plainrowheaders" with class="plainrowheaders leftalignrowheaders" or similar. So here's what I'm proposing (better suggestions for the class name are welcome):

.wikitable.plainrowheaders-center th[scope="row"] {
    font-weight: normal;
}

–

Before something is added here, it needs to be established that there is a general need for it, as Common.css is loaded unconditionally for everyone. There does not seem to be an actual need here; it just adds a superfluous option class. The goal for the plainrowheaders class is to emulate plain table cells in headers. -- [[User:Edokter]] {{talk}} 15:44, 2 January 2016 (UTC)

Putting the spec aside for argument's sake and accepting the "...goal for the plainrowheaders class is to emulate plain table cells in headers", why wouldn't this work for everybody?

/* Normal font styling for table row headers with scope="row" tag */
.wikitable.plainrowheaders th[scope=row] {
    font-weight: normal;
    /* @noflip */
    text-align: inherit;
}

Unless style="text-align: center" is also set on the table tag, the scope=row TH's still text-align left with a normal font weight for me (or is that 'just me'?). -- George Orwell III (talk) 18:08, 3 January 2016 (UTC)

No, that's 'just your browser'. The spec says nothing about text-alignment in <th>...</th>. Unless we explicitly specify the text alignment on an element, a browser will normally make its own choice. Most browsers will centre text in <th>...</th>, but a lot of Wikipedians have expressed a preference to see row headers left-aligned (and normal-weight) for some tables, which is why the argument was made to introduce the "plainrowheaders" class. Otherwise it was difficult to get the row headers marked up as headers for accessibility, because many editors wanted to keep the cells as <td>...</td> because it fitted how they thought the table should look (without any consideration for screen readers). --RexxS (talk) 20:01, 3 January 2016 (UTC)

Not exactly - you are right that it is the user agent that 'ultimately' determines the text-alignment and you are right about it needing to be set for agents to respond properly but it is also the spec that states what is expected to be defined in a compliant agent's stylesheet...

User agents are expected to have a rule in their user agent stylesheet that matches th elements that have a parent node whose computed value for the 'text-align' property is its initial value, whose declaration block consists of just a single declaration that sets the 'text-align' property to the value 'center'.^{19 sentences below quirks mode table in 10.3.9}

so obviously my browser works as expected by changing the forced text-align:left to 'something' allowing for the matching of text-align: 's initial value (which is LEFT btw [if direction is LTR]) This is needed to replicate the now deprecated align=center property/value for table tag(s).

I used inherit in common.css and it seems to work on test2 in spite of any .css from the MediaWiki code possibly 'interfering' with the example. -- George Orwell III (talk) 22:49, 3 January 2016 (UTC)

Here's a wiki-table:

I would expect the row header cell to be presented by most browsers as bold and centred.

Here's the same table but with the row header's style set to "text-align: inherit;":

I would expect the row header cell to be presented by most browsers as bold and centred, just as the first table. If your browser displays it as left-aligned, then either you have an unusual browser or some custom css. --RexxS (talk) 03:09, 4 January 2016 (UTC)

@RexxS: No relevant custom CSS. In Firefox 43.0.3 and Opera 12.17, it's left-aligned. That is what I would expect, since inherit instructs the element to use the styling of the parent element, which is a <tr>...</tr>. In Chrome 47; IE8; Opera 34.0; and Safari 5.1.7, it's centred. --Redrose64 (talk) 18:58, 4 January 2016 (UTC)

Thank you, Redrose64. As text isn't found directly inside any table element other than a cell, I can understand why a browser designer might choose not to respect inheritance of default text alignment. The lack of consistency in the implementation of 'inherit' within tables between major browsers suggests to me that we ought not to attempt to use it in these sort of cases. --RexxS (talk) 18:27, 5 January 2016 (UTC)

I've not seen the same desire expressed for normal-weight, centred text inside a row header. --RexxS (talk) 20:01, 3 January 2016 (UTC)

Nor have I. But that doesn't make using scope for formatting or eye-pleasing purposes right to begin with either. And if you're going to manually add scope=row to the th element in certain cases to trigger in part .plainrowheaders, then I don't see what the difference would have been in defining a class to achieve the same goal(s) and applying that to the parent tr or the th as warranted instead. -- George Orwell III (talk) 22:49, 3 January 2016 (UTC)

If it was just a question of "what is right", I wouldn't have found it necessary to spend many hours trying to convince other editors that they should be marking up row headers as headers for the benefit of the visually-impaired. The class "plainrowheaders" is merely presentational sugar that makes the markup more palatable to those editors. I've yet to see any similar argument to justify creating further classes. --RexxS (talk) 03:09, 4 January 2016 (UTC)

I would like to add a class for wikitables with no borders on its cells. The table would still have borders, and the header cells only on top and bottom (which perhaps could be disabled with another .borderless on the tr or th), but the data cells would not have any borders.

The application for this would be for some full-width tables that do want the wikitable's background styles, but not its border styles on all cells. To be concrete, I would like this for the player tables on football teams. Those currently all use a template that has a contested format because it does not use existing classes, making them appear bad in dark skins for example. A solution could be to convert them into wikitables, but then I'm sure there will be a revolt because of all the borders inside them, so wikitables without the data-cell-borders seems like a good compromise. –Sygmoral (talk) 05:24, 7 January 2016 (UTC)

Cell borders are basically required for

accessibility. --Izno (talk

) 12:24, 7 January 2016 (UTC)

Thank you for your answer. But I do not fully follow, as I do not see borders explicitly mentioned on that accessibility page. Could you please give an example of how someone may be disadvantaged due to lack of borders in a wikitable? I can understand it for small tables with small values, but wide tables with wide contents provide a clear enough overview thanks to all their whitespace. Can we consider this for those cases? –Sygmoral (talk) 19:09, 7 January 2016 (UTC)

After all, infoboxes and a few other standard tables don't have borders inside them either, so it must be acceptable in some cases. I can understand that it may be abused for tables where it should not be used, but then again, abuse is always possible with manual code. By the way, I suggested the .borderless classname because it is already used for infoboxes. –Sygmoral (talk) 19:34, 7 January 2016 (UTC)

It might be nice if nested hatnotes displayed inline. This would let us use two or more hatnote templates but display them as though they were a single template. CSS, example wikitext, and intended result follow:

CSS:

div.hatnote div.hatnote {
    display: inline;
    padding-left: 0;
}

Example wikitext:

{{hatnote|
{{distinguish|Foo}}{{other uses|Bar}}
}}

Intended resulting look of example wikitext:

A bit of an edge case (most pages only need one hatnote), but a short, simple improvement where applicable. {{Nihiltres |talk |edits}} 04:55, 18 January 2016 (UTC)

Wouldn't the correct improvement be to use the correct hatnote? Your case is covered by {{about3}} IMO. --Izno (talk) 12:13, 18 January 2016 (UTC)

@Izno: There are lots of pages which have multiple hatnotes for one reason or another, and I'd be surprised if all of them are potentially covered by existing templates. That said, this idea would in theory allow us to make hatnotes modular, and thereby eventually deprecate templates that exist purely to compound two or more of the others—like {{distinguish-otheruses}}, which is probably what you meant rather than {{about3}}? That seems like a good thing, but … one proposal at a time. {{Nihiltres |talk |edits}} 05:17, 19 January 2016 (UTC)

I found a decent example on

Selfref

}}, which is incompatible with all other hatnotes and which requires manual text rather than easy automatic hatnote formatting. Using my proposed system, it'd be trivial to make it nicer:

{{hatnote|
{{selfref|{{For|orphaned articles in Wikipedia|Wikipedia:Orphan}}}}
{{other uses}}
}}

{{Nihiltres |talk |edits}} 07:08, 19 January 2016 (UTC)

If we want a modular hatnote system, it should be build from the ground up. Nesting hatnotes is a hack though, so I'm not starting from that. -- [[User:Edokter]] {{talk}} 11:38, 19 January 2016 (UTC)

@Edokter: In what ways do you object to its hackishness? The obvious alternative would be to have it be not nesting, but some sort of envelope class ("hatnote-group"?) achieving a similar result.

Regardless, the focus here should not be on "modular hatnotes": those are just an obvious improvement that could be made given the possibility of compound hatnotes. In the short term, I'm working on standardizing existing, nonstandard hatnotes, mainly manually-formatted (:'') stuff that doesn't distinguish hatnotes from regular content, leading to practical problems like hatnotes showing up in Hovercards because TextExtracts doesn't distinguish the manually-formatted ones from the rest of the lead.

One of the most consistent problems I've had while making progress is editors resistant to breaking up a single manual hatnote into multiple nicely-templated ones, since individual hatnotes are naturally separated by unwanted linebreaks. It's easy, albeit inelegant, to reproduce the older single-line hatnote by using manual text and {{hatnote}}, but the obvious, elegant solution of concatenating two or more templates on the same line is just out of reach with the current CSS setup. {{Nihiltres |talk |edits}} 16:56, 19 January 2016 (UTC)

I'm a bit confused on few points... isn't the hatnote based equivalent to one of the given "problematic" examples --

{{selfref|For orphaned articles in Wikipedia, see [[Wikipedia:Orphan]].}}

-- replaceable/interchangeable with

{{hatnote|For orphaned articles in Wikipedia, see [[Wikipedia:Orphan]].|selfref=y}}

for starters?

And why do we want two or more hatnotes to render inline anyway? I'm fairly certain the opposite (or current approach) provides better readability/accessibility for mobile/tablet visitors for example. -- George Orwell III (talk) 23:13, 19 January 2016 (UTC)

@

selfref}} to mark it as such, and the {{other uses}} isn't a selfref. So if an external use stripped selfrefs, they'd get just the {{other uses

}} as desired, but it's still one line when not stripped out.

In the second… I'm not entirely sure why people want it that way, but I've had changes reverted to restore that style on multiple occasions with different Wikipedians. I think that having hatnotes uniformly on one line would make things more consistent, because right now certain combinations of hatnotes require two (or more) lines, whereas similar text constructed using other hatnotes only requires one line. For example, compare these:

1. {{redirect|A|B|C|and|D|other uses|E}}
   "A" redirects here. For B, see C and D. For other uses, see E.
2. {{redirect4|A|B|C}}{{other uses|D}}
   {{redirect4|A|B|C}}

   For other uses, see D.

If we decide that linebreaks are more usable, then we should be consistent with that, too. I mainly just want things to be consistent and clean. {{Nihiltres |talk |edits}} 05:40, 20 January 2016 (UTC)

I still don't get it - mostly because its still not clear to me if your concerned with insuring other entities "recycling" Wikipedia content elsewhere are not peppered with extraneous hatnote linkage useful to WP visitors but at the same time are not relevant (or are broken) in relation to that "recycled" content being viewed from elsewhere or if you're just looking to redesign the rendering behavior of hatnotes locally. You point to Orphan thinking that only the non-selfref other uses portion would be helpful to said "recyclers" somehow but currently neither of those templates would be "shown" to outside recyclers anyway as evidenced by the print version of the Orphan article.

In short, either Orphan is a bad example here or you're operating on assumptions or something rather than actual template behavior. -- George Orwell III (talk) 07:47, 20 January 2016 (UTC)

@George Orwell III: The orphan article is a bad example, if only because it's introducing the tangential issue of selfrefs. Here's my logic:

1. Hatnotes are currently applied inconsistently, with some pages using manual :'' formatting, which is semantically bad and demonstrably causes bad behaviour in Hovercards via TextExtracts.
2. I want to fix inconsistent hatnotes with nice templated ones
3. Some people don't like that multiple hatnote templates display on multiple lines (for whatever reason), and are willing to revert my fixes on those grounds.
4. It's probably a good idea for hatnotes to be on a single line, if only because it would be more consistent than our current system. See my {{redirect}} & {{redirect4}} example above, where very similar text has inconsistent linebreaks.
5. Hatnote collections that use two or more templates currently cannot be displayed on a single line without CSS changes.
6. Templates exist for certain combinations of hatnotes, but not all of them.
7. The alternative, writing out the compound hatnote as manual wikitext into a {{hatnote}}, is not good for maintenance.
8. Bonus: Sometime in the future, it might let us create a more modular hatnote system that would be better than our current one.

These lead me to think we should change the CSS to allow multiple hatnotes to display on a single line—the focus of this proposal. {{Nihiltres |talk |edits}} 16:57, 20 January 2016 (UTC)

Sidenote: I don't think we need to embed anything inside {{hatnote}}; div.hatnote + div.hatnote should work, shouldn't it? --Izno (talk) 12:38, 20 January 2016 (UTC)

@Izno: No, it wouldn't work, because that selector would only catch the second of a pair of adjacent hatnotes. Even if it caught both, it wouldn't let the combined hatnotes display as a block, which would disrupt their normal styling. {{Nihiltres |talk |edits}} 16:57, 20 January 2016 (UTC)

@

current guidelines concerning HatNotes whenever possible first, convert as many similar incarnations of "inconsistent" hatnotes as possible to use the current Hatnote meta-template and supporting hatnote Lua module scheme currently in place 'with nice [compliant] templated ones' afterward.

Only then would I believe it possible to consider the addition of any "option for inline rendering deviation". I think that would provide you with the modular approach you seek and most likely begin by requiring the introduction of 'wrapping' spans within the current DIV based foundation - something fairly easily accomplished en masse if done through the HatNote module (as that is why Module:s were introduced to begin with). Patching the .css to nullify 'original intent' in my view is just not the "right way" to go about any of this regardless. -- George Orwell III (talk

) 05:25, 22 January 2016 (UTC)

Wikipedia:Hatnote says it pretty explicitly: In most cases, hatnotes should be created using a standard hatnote template as illustrated below. This permits the form and structure of hatnotes to be changed uniformly across the encyclopedia as needed and the templates to be excluded in print. While it only implicitly favours non-generic hatnotes (i.e. {{about}} or {{redirect}} etc. over {{hatnote}}), it does explicitly favour single-line hatnotes, though without giving a justification. The guideline is pretty nebulous (and probably out-of-date; I just fixed instances of :'' formatting there), so improvements there might be something to start an RfC over or something.

This particular proposal is dead in the water, so I'll abandon it for now, with an eye to approaching the desired fixes from a different direction (e.g. perhaps I can create a unified template to support more edge cases and deprecate many of the current zoo of templates that currently exist) sometime in the future. {{Nihiltres |talk |edits}} 22:29, 30 January 2016 (UTC)

Hi all,

I propose to add the following CSS:

@media only screen and (max-width:768px) {
	div.thumb {
		float: none;
		clear: none;
		margin: .5em auto;
	}
	div.thumbinner {
		margin: 0 auto;
		max-width: 100%;
	}
	div.thumbinner img {
		max-width: 100%;
		height: auto;
	}
}

This will reposition image thumbnails to be centered and to clear other content on narrow pages. This is similar to how the mobile interface positions images in narrow views. If this is successful, I'll upstream this into our central repository. —TheDJ (talk • contribs) 10:04, 2 December 2015 (UTC)

Anyone ? Or shall I just flip the edit request button ? —TheDJ (talk • contribs) 14:21, 4 December 2015 (UTC)

Let me test it for a bit. -- [[User:Edokter]] {{talk}} 18:25, 4 December 2015 (UTC)

The a > img selector needs to be tightened, as non-thumb images in tables resize to 1x1. See List of atheists (surnames A to B) for example. -- [[User:Edokter]] {{talk}} 18:33, 4 December 2015 (UTC)

@Edokter: It seems we can safely remove max-width from that rule and we would be just fine. —TheDJ (talk • contribs) 19:21, 4 December 2015 (UTC)

That would degrade pages with images larger than the viewport though... We could also cancel it out when inside a table. There would still be problems if it were used inside an element with table styling, but those case are probably really minimal.. And it doesn't seem there is actually any other way to do responsive image sizing inside tables... —TheDJ (talk • contribs) 20:08, 4 December 2015 (UTC)

If tables are targeted, then where does it end. Can't we just target thumbs for now? -- [[User:Edokter]] {{talk}} 21:22, 4 December 2015 (UTC)

Made some adjustments and targeted only thumbs. Can you test this? -- [[User:Edokter]] {{talk}} 18:43, 5 December 2015 (UTC)

That works, though we won't have responsive sizing for inline images then. But honestly, that doesn't seem possible at all if we want to keep support for using them inside table layouts. —TheDJ (talk • contribs) 13:02, 7 December 2015 (UTC)

Inline images (like flag icons) should probably be left untouched anyway. I can't think of any other uses, except maybe the ones taking a separate paragraph; but those are hard to taregt as well. And tables are tables; they are always mobile-unfriendly. -- [[User:Edokter]] {{talk}} 16:58, 7 December 2015 (UTC)

Anyone care to deploy this ? —TheDJ (talk • contribs) 16:53, 2 February 2016 (UTC)

 Done. -- [[User:Edokter]] {{talk}} 17:13, 3 February 2016 (UTC)

@Edokter: Can this change be undone, there is no consensus for it to be imposed on en-Wiki. It is ruining articles having images centered with no option to force them left or right. See discussion at VPT on en-Wiki. Mjroots (talk) 18:22, 3 February 2016 (UTC)

There was no consensus not to implement it, either. Also, it wasn't "imposed on en-Wiki"; it was done entirely by en-Wiki itself, with zero outside involvement. WhatamIdoing (talk) 19:53, 5 February 2016 (UTC)

I reverted, since at least one user is reporting adverse effects, see Wikipedia:Village pump (technical)#Image display issue. --Redrose64 (talk) 21:10, 3 February 2016 (UTC)

I suggest tweaking the CSS for .tocnumber to use a grey color.

This would make it a lot easier to read the Table of Contents, by more clearly distinguishing the content (Headings) from the metadata (section numbers). Especially if the Headings start with numbers.

The code I use/suggest, is:

/* Tweak Table of Contents boxes, to have grey numbers */
.tocnumber {color:#333 !important;}

Any support/feedback/etc would be appreciated.

I've also suggested that this would be a good change for the default in MediaWiki, and have proposed it at phab:T125317. Trying it here first, was suggested by TheDJ, and seems like a good idea. Thanks. Quiddity (talk) 20:48, 23 February 2016 (UTC)

I like the gray; have you checked contrast to ensure it makes at least AA contrast delta? --Izno (talk) 20:57, 23 February 2016 (UTC)

Just noting: the tocnumber already has #333 as color. -- [[User:Edokter]] {{talk}} 21:04, 23 February 2016 (UTC)

My bad... that is the NewImageThumb gadget. (Give it a try.) -- [[User:Edokter]] {{talk}} 21:10, 23 February 2016 (UTC)

@Izno: According to Snook, it's fully AAA compliant against the #F9F9F9 background that monobook provides for me. In fact, it's fully compliant against any grey background lighter than #D9D9D9 --RexxS (talk) 22:17, 23 February 2016 (UTC)

Can we avoid using !important? That annotation gets overused, in most cases careful choice of selector eliminates any need for !important. Overuse of !important causes its effect to be diluted. Think of it like this: if lots of declarations have !important, what do people do when they want to override one of those? There is nothing in CSS to mean "even more important than !important", but there are many ways to increase a selector's specificity. --Redrose64 (talk) 10:47, 24 February 2016 (UTC)

@Redrose64: Suggestions/improvements welcome! Although in this case, my hope is that it will be a resounding success here at Enwiki, and then will become a global default soon thereafter, at which point it will be done more 'properly' as it were. (I.e. ongoing progress in https://gerrit.wikimedia.org/r/#/c/272708/ ). Quiddity (talk) 19:14, 24 February 2016 (UTC)

Current navbox:

Proposal:

Code:

.collapseButton a {
	padding: 0 2px;
}

Anyone else think that the collapse buttons for navboxes needs some work? Adding a bit of padding to the clickable area would be a minor improvement, in my opinion. (I also don't like that they change widths when clicked, but that's for another day.) --Yair rand (talk) 12:58, 22 February 2016 (UTC)

I prefer the unpadded version; why do you think this needs change? What are you looking to improve?

Aside: I'd prefer us to the use the mw-collapsible class, but that has a known regression for en.WP over 4 years since deployment.--Izno (talk) 13:10, 22 February 2016 (UTC)

It would make it more inline with the current section [ edit ] links, which use 0.25em between the brackets. But then I would prefer a wider solution to cover all spacing of brackets containing links. -- [[User:Edokter]] {{talk}} 21:06, 22 February 2016 (UTC)

+1. --Yair rand (talk) 19:22, 24 February 2016 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The current declaration for .navbar ul causes line breaks to appear between the edit link and the closing square bracket (see: Template:Crossrail RDT). To fix this, display:inline should be changed to display: inline-block. Sceptre ^(talk) 17:53, 25 February 2016 (UTC)

I'm not seeing the fault (which browswer?), and technically, the display setting should not affect what's inside the container. Also, have you tested inline-block will not break other brosers? -- [[User:Edokter]] {{talk}} 19:19, 25 February 2016 (UTC)

The fault occurs, apparently, in Safari on OS X only. Sceptre ^(talk) 20:56, 26 February 2016 (UTC)

I see that the title of that template is built in an unconventional way (with a left margin of 55px), which is really squeezing it tight for the navbar. It may just be that the navbar is one pixel short if you happen to have a slightly larger font set. Perhaps the better fix is to use a scaling unit in Module:Routemap instead? -- [[User:Edokter]] {{talk}} 09:55, 27 February 2016 (UTC)

There is a proposal to move the .hatnote styles from MediaWiki:Common.css and MediaWiki:Mobile.css inline to Module:Hatnote because currently they generate a flash of unstyled content on mobile. Please see the discussion at Template talk:Hatnote#Please apply inline style to .hatnote class. — Mr. Stradivarius ^{♪ talk ♪} 23:50, 24 March 2016 (UTC)

If that is the argument, then everything should be made inline... well, obviously not. Mobile should fix its loading of Mobile.css instead. -- [[User:Edokter]] {{talk}} 12:04, 25 March 2016 (UTC)

I propose reducing the padding in the WikiEditor's dialog windows, which make them too big. This is particularly a problem with the Search & Replace window, because while it is open you need to be able to see the textarea as well, but the window may cover part of it. I have been using this code for a long time, and it works great.

.wikiEditor-toolbar-dialog {border: 1px solid lightgray;}
.wikieditor-toolbar-field-wrapper { padding-bottom: 5px;}
.wikiEditor-toolbar-dialog .ui-dialog-content { padding: 10px 10px 5px !important;}
.ui-dialog-buttonpane button {margin-top: 0; margin-bottom: 0;}
body .ui-dialog .ui-dialog-titlebar {padding-top: 5px !important; padding-bottom: 5px !important;}
body .ui-dialog .ui-dialog-buttonpane { padding: 0.1em 1.3em 0.3em !important }

--V111P (talk) 21:51, 6 May 2016 (UTC)

I don't think the padding is extreme, but if any tweaking is to be done, it should be done in MediaWiki itself, since it usess the OOUI library. You know you can resize the dialog? -- [[User:Edokter]] {{talk}} 07:41, 7 May 2016 (UTC)

The problem is not just with the padding at the edge of the window, but mostly with the padding above and below the elements inside of it. I agree that is should be fixed in MediaWiki, but we can't do much about that. Anyway, I just wanted to share my solution to this problem. --V111P (talk) 22:15, 7 May 2016 (UTC)

I propose to add the following fragment to Common.css

.client-js .collapsible.collapsed > tbody > tr:not(:first-child) {
	display: none;
}

This should slightly improve the reflows of content caused by collapsing of content, in the few cases where we already know that they should be initially collapsed. —TheDJ (talk • contribs) 20:14, 19 May 2016 (UTC)

Wait, we will also need a change to common.js of course. —TheDJ (talk • contribs) 20:21, 19 May 2016 (UTC)

Accompanying JS change. Testpage —TheDJ (talk • contribs) 20:38, 19 May 2016 (UTC)

 Done. -- [[User:Edokter]] {{talk}} 06:39, 20 May 2016 (UTC)

This edit request to MediaWiki:Mobile.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I propose we add the following fragment to Mobile.css

.flagicon img {
    min-width: 25px;
}

This fixes one specific and often occurring case of phab:T116318. —TheDJ (talk • contribs) 13:54, 17 March 2016 (UTC)

Yeah, took me a moment to understand that bug report, because the table-embedded flags are so small they just look like dots.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:54, 7 April 2016 (UTC)

 Done. Made it 25px because of the border flags have. -- [[User:Edokter]] {{talk}} 08:24, 20 May 2016 (UTC)

How to edit the font style of Wikipedia's mobile version, similarly as we to those of

@

talk

) 08:32, 21 May 2016 (UTC)

Regarding the following:

/* Inline divs in ImageMaps (code borrowed from de.wiki) */
.imagemap-inline div {
    display: inline;
}

I think this class can be removed after some cleanup (see search).

The definition has been added with this edit in January 2008 (copied from dewiki) and is quite nonsensical because it never worked properly: it totally breaks the blue "i" icon (see mw:Extension:ImageMap for examples) because it applies display:inline to too many elements.

Actually, the only real use-case of this class were "fake" imagemaps that consist of a single clickable area and have no "i" icon. Such imagemaps have in the past been widely used, but since October 2008 they are no longer necessary because of the "new" [[File:Example.svg|link=...]] syntax.

It has already been removed at dewiki. --Entlinkt (talk) 21:43, 22 May 2016 (UTC)

Found only one article still that stil used it (fixed). The rest is all user space , most of which are copies of Common/Vecotr.css, and one template talk page. I say it is safe to remove, so consider it  Done. -- [[User:Edokter]] {{talk}} 22:12, 22 May 2016 (UTC)

See Wikipedia:Village pump (technical)#Highlight of "updated since my last visit". PrimeHunter (talk) 22:47, 26 May 2016 (UTC)

The !important annotation is a cop-out. In the majority of cases, it's better to increase the specificity of the selectors. --Redrose64 (talk) 23:40, 26 May 2016 (UTC)

Sounds fine. I have limited CSS knowledge but have added span. in span.updatedmarker.[8] PrimeHunter (talk) 10:28, 27 May 2016 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

To ensure uniform appearance across different browsers and platforms and compliance with

small {
    font-size: 85%;
}

(Suggested by Izno on my edit request at Template talk:Unsigned.)

It does seem a little strange that we allow browsers latitude to interpret <small>...</small> themselves. In many cases, of course, it's best to give flexibility to the user agent, but when there are clear accessibility implications - as in tiny text size - I agree that we should be specifying how the tag should render. --RexxS (talk) 15:14, 10 June 2016 (UTC)

Both Chrome and Firefox translate it to use font-size:smaller. It is there that the discrepancy occurs. This might fix <small>, but not any style using font-size:smaller directly (see here). But it's a start. -- [[User:Edokter]] {{talk}} 15:54, 10 June 2016 (UTC)

Firefox 3.0 and MSIE 5.5. :D --Izno (talk) 16:26, 10 June 2016 (UTC)

Agreed, let's start somewhere. It would be good to see if we have any instances of font-size out and about in the wiki-world (template or otherwise). --Izno (talk) 16:27, 10 June 2016 (UTC)

There's plenty, but most use relative values (like 85%) instead of keywords (such as 'x-large' or 'smaller'). It's those keywords that need attention. Unfortunately, most of them are emitted from MediaWiki itself. -- [[User:Edokter]] {{talk}} 19:43, 10 June 2016 (UTC)

I think either is undesirable from the point of view of a gadget which works on certain assumptions, and which obviously can't deal with inline CSS. --Izno (talk) 21:11, 11 June 2016 (UTC)

I bring to your attention the

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Old revision of MediaWiki:Common.css to Old revision of User:Matt Fitzpatrick/common.css (diff)

Will allow a tableless layout update to Template:Sister project links (sandbox) (testcases). Incorporates feedback from Wikipedia:Village pump (technical)#CSS support for tableless layouts.

Matt Fitzpatrick (talk) 22:30, 5 July 2016 (UTC)

Quick question. Which other templates might this change affect? — Martin (MSGJ · talk) 10:58, 6 July 2016 (UTC)

@MSGJ: Module:Message box also puts class="mbox-small" or class="mbox-small-left" on anything using the metatemplates {{ambox|small=left}} {{tmbox|small=yes}} {{ombox|small=yes}}. I didn't see any differences in Template:Ambox/testcases, Template:Tmbox/testcases, Template:Ombox/testcases with or without my user CSS. These metatemplates would have to remain <table>s for now, since there are other joined table.*mbox selectors further up in Common.css that I'm not messing with (yet). Matt Fitzpatrick (talk) 22:41, 6 July 2016 (UTC)

Happy to make the change later today unless there are any comments from others — Martin (MSGJ · talk) 12:22, 7 July 2016 (UTC)

Done — Martin (MSGJ · talk) 10:33, 8 July 2016 (UTC)

This edit request to MediaWiki:Group-templateeditor.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The shading on the text box is pretty dark, relative to its normal color, and should be changed from #FFDBDB to #FFE0E0 for readability. (This suggestion comes after too much time spent getting annoyed over the color instead of being warned, as I presume the original intention was.)

 Done — xaosflux ^Talk 02:02, 13 July 2016 (UTC)

Sorry, didn't think I'd be back so soon.

We had to revert a change at Module:Portal bar, taking it from a div-ul back to the old nested table-table-div-ul. It was using the navbox class to overlap borders, as in Template:Portal bar/testcases#Adjacent navboxes, and the margin declarations to do that are under specific table.navbox selectors in MediaWiki:Common.css.

I can get Portal bar back to a div-ul, with a change to those selectors. Something along the lines of Old revision of User:Matt Fitzpatrick/common.css. I've looked through the CSS of the desktop skins, and couldn't find any margin declarations that would require the extra specificity of table.navbox. On Template:Navbox/testcases, if I turn off the site table.navbox rules, my user .navbox rules achieve the same appearance for all the Template:Navbox/testcases and desktop skins. Does this change seem safe and sane? I'll put up an edit request if it seems okay. Matt Fitzpatrick (talk) 21:33, 13 July 2016 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Edit requested

copy Old revision of User:Matt Fitzpatrick/common.css to MediaWiki:Common.css (compare)

Changes

lowers specificity of table.navbox selectors to .navbox so any element can match

box-sizing: border-box; so a non-table .navbox still uses the table box model

Left notices at Template talk:Portal bar, at Template talk:Navbox just in case, and for User:Dinoguy1000 who was working on something potentially related at Module:Navbox/sandbox. Matt Fitzpatrick (talk) 23:57, 14 July 2016 (UTC)

 Done by MSGJ. — xaosflux ^Talk 12:00, 15 July 2016 (UTC)

(Pinging Sameboat and Useddenim.) For a while, I've been trying to fix the multiple issues with the display of {{Routemap}} in Minerva / mobile view. However, there are a few remaining problems which can't be solved simply by editing the module (test in Template:Routemap/testcases):

• On narrow pages in Minerva, due to usage of nested tables each row of icons appears to be stuck to the left, due to a rule for .content table which applies width: 100% !important.^[a] Could this be overridden by adding a CSS class or custom attribute to each row's table cancelling that rule?
• Collapsible rows (1, 2) do not work in mobile view, as the JavaScript for collapsibility isn't actually loaded. For link 2, since currently all the rows (collapsible and replaced) are shown, could a new CSS class (perhaps routemap-replaced with rule display:none) be added to eliminate the display problem?^[b]

Thanks, Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 10:56, 29 July 2016 (UTC)

I was directed here from

What we would do here is not create a template per se, but create a class that could be used by a template, much like the hlist class is used by the {{hlist}} template. This new class might be as simple as taking the various rules matching existing hlist class, copying them and altering where appropriate. The rule which presently adds the dots is:

.hlist dd:after,
.hlist li:after {
    content: " · ";
    font-weight: bold;
}

we would begin by removing the second declaration and altering the first to content: ", "; --Redrose64 (talk) 08:45, 3 August 2016 (UTC)

We don't actually need to copy anything except for the rule specifying the list item separator--we can simply add a .hlist-comma class to each of the CSS declarations. --Izno (talk) 13:18, 3 August 2016 (UTC)

Why do you need an HTML list for a comma separated list ? What does it add ? The original hlist was designed very much specifically for dealing with a practice inside navboxes that created an accessibility problem. But I see no such problem here. It's possibly of course, but all this complexity has a price as well. —TheDJ (talk • contribs) 13:39, 3 August 2016 (UTC)

We often get requests from editors/readers who object to the middot as a visual separator in an infobox (as opposed to a navbox), and prefer commas as being more consistent with normal prose. That loses the benefits of semantic markup and the ability of a screen reader to navigate back and forth through a long list. The lastest example is at Template talk:Infobox album #Harmonization with other music templates as the OP indicated. Having a horizontal list class that used a comma separator might satisfy all points of view. There's been a demo of a 'cslist' class in my User:RexxS/common.css for a couple of years now. I'm not able to judge whether the extra complexity is too big a price to pay for the extra functionality. --RexxS (talk) 14:54, 3 August 2016 (UTC)

Is there an expectation that we need to accommodate large lists in infoboxes? That seems to defeat the purpose of an infobox. Regarding semantic value, we don't ask for users, in prose, to provide that semantic value (though clearly HTML + CSS support that), so that removes another large need (and would seem to indicate we also do not need such in infoboxes). The place I have seen hlists where a comma separated list might be valuable would be in {{sidebar}}, but even there, I think hlist alone is Good Enough. --Izno (talk) 15:08, 3 August 2016 (UTC)

Template:Infobox album which kicked off this debate has examples of larger than normal lists - genre and producer commonly attract multiple items. Count the number of "associated acts" in many examples of Template:Infobox musical artist, and so on. I'm not promoting having long lists in infoboxes, merely commenting that they exist and we ought to cater for them as best we can. As for semantics, can you tell me whether |producer=Tom Hamilton, Aerosmith means that the producer was Tom Hamilton (musician) (the bass guitarist in Aerosmith) or that perhaps Tom Hamilton Jr. and Aerosmith were both credited as producers? Why shouldn't we mark up a long prose list as a HTML list if it provided benefit to screen readers and content re-users, anyway? What's to stop us if the css existed? --RexxS (talk) 16:15, 3 August 2016 (UTC)

A quick re while I consider the rest of your questions: I understand your problem case ("Tom Hamilton, Aerosmith") but I don't think it makes your point for you. It is a problem case regardless of the HTML underlying, for visual users, since most will not be bothered to check the HTML or the wikitext, for the vast majority of persons are readers and not editors. (Aside: My inclination is to interpret such as two separate producers.) --Izno (talk) 19:37, 3 August 2016 (UTC)

Don't forget all the readers who receive the information from our articles via third-parties, whose automated tools can extract the intended meaning if we use semantic markup. Do we know how many of those there are? In any case, surely all the readers who don't bother to check are no worse off if the HTML provides the correct meaning, while everyone else benefits. There's no downside in that equation. --RexxS (talk) 20:07, 3 August 2016 (UTC)

On pages with pending changes protection, there is currently both the pending changes notice added by mediawiki and the protection template. The template is useful since it categorizes and such, but having also the notice is redundant. It is now possible to hide the notice without also hiding it when the page actually has pending changes, in which case it's useful. So I suggest to hide them when there are no pending changes using:

.flaggedrevs_draft_synced,
.flaggedrevs_stable_synced {
    display: none;
}

Cenarium (talk) 18:46, 23 September 2016 (UTC)

I would think this would best be upstream, since I agree that we should not see a synced notice, with or without a secondary template to indicate flagged revs protection. --Izno (talk) 18:59, 23 September 2016 (UTC)

This already took a while to get this change in, I don't think we could have anything more done in the code on this subject in a reasonable amount of time (it would need a configuration switch since other wikis may want to keep it in, etc). Cenarium (talk) 15:39, 24 September 2016 (UTC)

.IPA {
	font-family: Gentium, GentiumAlt, DejaVu Sans, Segoe UI, Lucida Grande, Charis SIL, Doulos SIL, TITUS Cyberbit Basic, Code2000, Lucida Sans Unicode, sans-serif;
	font-size: 110%;
}

.IPA, .IPA * {
	font-style: normal;
}

I am puzzled that there are no CSS properties assigned to languages (lang="") and the IPA class, as there are on Wiktionary. Is there perhaps another CSS file that has these? It's certainly possible that the idea has never been implemented, since languages are not consistently tagged on Wikipedia.

If not, I propose that the following code be added. It is essentially a copy of the CSS on Wiktionary. These are fonts that support the characters in the International Phonetic Alphabet, which uses the IPA class on Wikipedia. IPA transcriptions are never supposed to be italicized, hence font-style: normal;. — Eru·tuon 19:35, 5 November 2016 (UTC)

I believe this text was here but was removed. Either way, I think {{IPA}} already has the CSS in-line. Try searching the archives above to verify or the template talk page of the IPA family templates. --Izno (talk) 04:30, 8 November 2016 (UTC)

It was removed since basically only Windows XP required it, and XP is no longer supported. In other situations, these declaration broke as much as they fixed. —TheDJ (talk • contribs) 09:40, 8 November 2016 (UTC)

@

IPAlink}} or {{IPAc-en}} or any of the other IPA templates that I am aware of. @TheDJ: What do you mean about this CSS breaking things? I don't understand; it's valid and should work. — Eru·tuon

14:10, 8 November 2016 (UTC)

If you mess with the order of the rendering engine you will get about as many breakages as you are fixing. We saw cases, where the defaults were giving just fine results on some platform, and with changes in the font order were suddenly selecting very old and incomplete fonts that had been installed by old versions of Microsoft office for instance that degraded the experience. There was always something, and no definitive solution. In the end, we just opted to get rid of it, because most modern browsers just do proper font selection and glyph fallback and don't have an actual problem that has to be dealt with. —TheDJ (talk • contribs) 14:29, 8 November 2016 (UTC)

I don't suppose any knows of a reasonable way to use a different CSS per category? I know you can use namespace codes to change it by namespace, but changing CSS by way of the [[Category:]] on the page is not an ability I can find anywhere. I'm really looking for a solution to add a graphic banner, or a template, or somethin', based on Category. --146.200.233.235 (talk) 21:49, 9 November 2016 (UTC)

Not possible through CSS alone, but you could use some JS to make it work, using mw.config.get( 'wgCategories' );. --Yair rand (talk) 21:55, 9 November 2016 (UTC)

Every page has two classes that (I think) are unique to that page, they are named in the class= attribute of the <body>...</body> element. For instance, this page belongs to the classes page-MediaWiki_talk_Common_css and rootpage-MediaWiki_talk_Common_css. This page is in two categories, which themselves have two unique classes each: Category:MediaWiki messages with interface explanation has the classes page-Category_MediaWiki_messages_with_interface_explanation and rootpage-Category_MediaWiki_messages_with_interface_explanation, and Category:Wikipedia pages with to-do lists has the classes page-Category_Wikipedia_pages_with_to-do_lists and rootpage-Category_Wikipedia_pages_with_to-do_lists. Notice how colons, spaces and full stops are both replaced by underscores. --Redrose64 (talk) 00:21, 10 November 2016 (UTC)

These are both very helpful comments, thank you! I'll look into this <3 --146.200.233.235 (talk) 12:38, 12 November 2016 (UTC)

See Template:UK Wikipedia meetups. The London row begins with a whole series of dots before the first actual entry is reached (14 Aug 2011). These dots are from the hlist class, they used to be suppressed because something recognised that the <li>...</li> element was empty (it's empty because Template:UK Wikipedia meetups/date has a date test). Now the dots are displaying, even though the li is still empty. Any idea why the dots are no longer suppressed? --Redrose64 (talk) 19:57, 6 August 2016 (UTC)

There's some stuff going on with wikitext -> HTML conversion related to removing Tidy, which may (or not!) be related. --Izno (talk) 12:42, 8 August 2016 (UTC)

[9] 82.73.181.57 (talk) 13:05, 13 August 2016 (UTC)

moved the bullets inside the parser function, so probably fixed in that case? Frietjes (talk) 14:00, 13 August 2016 (UTC)

Maybe someone could help with the implementation of hlist on yiwiki. It does not function properly for nested lists. See yi:מוסטער:מעטראפאליטאן ליניע סטאנציעס Any idea how to get this to work? --Redaktor (talk) 17:52, 16 November 2016 (UTC)

I've made a proposal at Wikipedia:Village pump (proposals) #Regularise spacing between paragraphs on talk pages to regularise the spacing between "paragraphs", both indented and unindented, on talk pages. As this will arrive here if it gains support, I wanted to give a courtesy notification to those watching this page who may have some useful input. Cheers --RexxS (talk) 18:58, 1 September 2016 (UTC)

As there were four positive comments (Izno, Johnuniq, Enterprisey, SMcCandlish) made at VPP before it was archived, I'll make the request here for implementation as an RfC. --RexxS (talk) 22:45, 16 November 2016 (UTC)

Hello @Seddon (WMF): - can you please explain this edit you just rolled live without so much as an edit summary? — xaosflux ^Talk 02:50, 8 December 2016 (UTC)

When replying, please identify if this is an official

OFFICE action intended to override the community consensus process on the English Wikipedia. — xaosflux ^Talk

03:12, 8 December 2016 (UTC)

Hey @

OFFICE action, it's not been done although I was asked to do this as part of my role at the WMF (which is why I used my staff account rather than my volunteer admin account). Basically there is a partnership going on between a number of community groups including Women in Red, Wikimedia UK, Wikimujeres and other affiliates relating to [10]. The was WMF asked late into the process if we could take our fundraising banners during the partnership due to a potential conflict of interest due to the BBC being a public service broadcaster. Given the scale of the project, and the extent and scale of what was being asked when the fundraiser was already in progress, we were trying to find the best alternative to support the volunteers as best we could to make sure this project could go ahead and not have hours of volunteer time wasted. The only way we could think of what to physically suppress fundraising banners on a list of pages involved. Doing that via the site common.css was the only viable alternative. It will only need to be in place for around 24 hours and after that the change can be rolled back. Apologies for not going through the proper channels. Seddon (WMF) (talk

) 03:27, 8 December 2016 (UTC)

Thank you for the update - hopefully we can find a better solution for next time. Please follow up on the removal after the conflicting event. — xaosflux ^Talk 03:29, 8 December 2016 (UTC)

(see related campaign here: 100_Women_(BBC)#2016) — xaosflux ^Talk 03:33, 8 December 2016 (UTC)

Hey, Wikimedia now have a brand-new color palette that passes WCAG standard for accessibility (for color-blind people). These colors are being used all across the interface. For example wikipedia.org now uses these colors or OOjs UI colors are now align with these colors. I hereby suggest to change interface colors too to give readers a standard UI instead of super colorful one making the whole website ugly. For example see what I've done in in Persian Wikipedia :)Ladsgroup^overleg 10:03, 26 November 2016 (UTC)

I cannot see YELLOW90 #fef6e7 or BASE90 #f8f9fa from the white background on my display. Additionally, ACCENT90 #eaf3ff and RED90 #fee7e6 are difficult to see. — Dispenser 17:58, 26 November 2016 (UTC)

1- The Yellow90 is incorrect. The correct one is YELLOW90 #fef6e7. 2- I think these colors should be background for mbox-es to make it easier to read inside them. For borders, I think using the primary colors such as Yellow #fc3 or Blue #36c is the sane option here (See my changes in fawiki common.css) :)Ladsgroup^overleg 18:13, 26 November 2016 (UTC)

Fixed the color. Displays can vary significantly in color reproduction and most designers are unaware of this. I just wanted to point out it as colors from #f0f0f0 to #ffffff risks turning to white on crappy displays. — Dispenser 04:57, 30 November 2016 (UTC)

A color in itself says nothing. It only matters how the colors of various elements are combined. —TheDJ (talk • contribs) 11:12, 30 November 2016 (UTC)

@Ladsgroup: Can you be more specific about which elements you want to change ? —TheDJ (talk • contribs) 11:12, 30 November 2016 (UTC)

@TheDJ:. Thanks. Let me explain in details:

.infobox

border: #aaa to #a2a9b1 background: #f9f9f9 to #f8f9fa (same for .infobox.bordered and other similar ones)

table.ambox

#aaa to #a2a9b1, #1e90ff to #36c (important IMO), #fbfbfb to #f8f9fa

table.ambox-speedy

#b22222 to #d33 and #fee to #fee7e6 (Same for table.ambox-delete)

table.ambox-content

#f28500 to #ac6600

table.ambox-style

#f4c430 to #fc3

table.ambox-protection

#bba to #a2a9b1

Everything about ambox can be applied to imbox, fmbox, cmbox, ombox, etc. See this :)Ladsgroup^overleg 16:16, 30 November 2016 (UTC)

Request for editing Mediawiki:common.css

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Per Special:PermaLink/753600253#RfC for changing colors to align with Wikimedia UI and Special:PermaLink/754556867#Reopening discussion about aligning colors with Wikimedia color palette and no objection after the given time, please change content of Mediawiki:Common.css with content User:Ladsgroup/common.css. This change is barely noticeable. Thanks. :)Ladsgroup^overleg 02:59, 14 December 2016 (UTC)

 Done Legoktm (talk) 07:57, 14 December 2016 (UTC)

There is a clear consensus for the proposal, which was implemented here. Cunard (talk) 05:09, 19 December 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I propose we modify Common.css to make the spacing between paragraphs on talk pages the same for indented posts as it is between unindented posts. --RexxS (talk) 22:49, 16 November 2016 (UTC)

Background

Rather than wait for a solution that might never materialise, I'd like to see us do something about a perennial problem on talk pages.

It is obvious at present that the spacing between paragraphs in an unindented post is different from that between "paragraphs" in an indented post.

You only have to look here.

And here to see what I mean.

Editors get into the bad habit of leaving a space between successive indented posts to improve the readbility of the thread.

Unfortunately, as anyone who reads

screen readers

.

Many of them will tell the listener that a nested set of

description lists

has been closed and a new nested set of description lists has been opened.

That's not ideal, so we need the ability to let pseudo-paragraphs in indented posts stand out a little more, while not closing the nested lists for a screen reader. Let's say we want them to stand out to the same extent as normal unindented paragraphs do. I tried the following in Special:MyPage/common.css:

• .ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;}

Now I see each paragraph on talk pages with the same spacing whether it's indented or not. That works well to my eyes - after just a couple of minutes the talk pages now look "natural" - so much so that I didn't feel the need to tinker further by adding extra space between each person's post (just increase the margin-top for .ns-talk .mw-body-content dl).

What do others feel? Would this be a sensible improvement for both regular readers and those using screen readers?

May I suggest that threaded discussion takes place in the Discussion section, not the !votes sections, please? --RexxS (talk) 22:52, 16 November 2016 (UTC)

Support

1. Support as proposer
2. Strong Support per nom. I was originally fixing these LISTGAP issues myself, but stopped after people complained on my talk page that I was editing others' posts. (However, this will do nothing to stop the * -> :: issue that was more common). Pppery 23:02, 16 November 2016 (UTC)
3. Support We need experience from trying this to determine whether there would be any unwanted side-effects, but there is a problem as others have "fixed" my correct indentation because of the lack of vertical spacing. Johnuniq (talk) 02:47, 17 November 2016 (UTC)
4. Support, per excellent reasoning by the proposer and my previous support of this idea. Enterprisey (talk!) 04:43, 17 November 2016 (UTC)
5. Support. A good idea can often justify itself. Best regards, Codename Lisa (talk) 07:05, 17 November 2016 (UTC)
6. Support Seems like a good idea —TheDJ (talk • contribs) 09:19, 17 November 2016 (UTC)
7. Support Oh man, that spacing has always annoyed the heck out of me. Please make it happen! --SubSeven (talk) 19:13, 17 November 2016 (UTC)
8. Support There are various other spacing issues to fix, too, such as ordered and unordered lists having uneven indentation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:02, 18 November 2016 (UTC)
9. Support: I like this idea to make the spacing regularized. —MRD2014 (talk • contribs) 16:18, 20 November 2016 (UTC)
10. Support: I was worried there'd be some negative side-effects, but I tested the code and the result looks fine to my eyes. This is a problem that should have been fixed years ago. — Eru·tuon 17:28, 20 November 2016 (UTC)
11. Support per above. --TerraCodes ^{(talk to me)} 09:00, 27 November 2016 (UTC)

Oppose

Discussion

Text in one paragraph.

Text in the next paragraph, with two line breaks above it.

versus

Text in one paragraph.

Text in the next paragraph, with only one line break above it.

I like the goal of the proposed code; it's a problem that I've noticed. But before supporting it, I have to ask: does this CSS code cause bad display for paragraphs indented with : that have two newlines between them? I mean, would it make the two examples in the box above be separated by different amounts of vertical space, with the example with two line breaks having more vertical space between the two lines than the one with one line break? I think ideally it should make them look the same. That way existing talk pages won't be messed up too much. Then again, maybe this is impossible. — Eru·tuon 03:11, 17 November 2016 (UTC)

Or, perhaps the goal should not be to have them look the same, but just that the one with two line breaks not have so much vertical space that it's ugly (though that's an aesthetic judgement and it may be difficult to define). — Eru·tuon 03:16, 17 November 2016 (UTC)

@

WP:INDENTGAP. What RexxS is proposing will help to discourage multiple line breaks. --Redrose64 (talk

) 13:48, 17 November 2016 (UTC)

@Redrose64: Very well, I shouldn't and other people shouldn't be using two line breaks, but I'm sure they do sometimes. Should the CSS account for that or not? — Eru·tuon 15:28, 17 November 2016 (UTC)

One other possibility would be to also add something like:

• .ns-talk .mw-body-content dl {margin-top:0.6em;}

which would increase the vertical spacing between different editors' comments, not the paragraphs. You can try it out in your own Special:MyPage/common.css and tweak it to see the effect (or just keep it if you like it enough). --RexxS (talk) 18:29, 17 November 2016 (UTC)

• If someone turns this into a gadget, before trying to add it to Common.css, then it would be a lot easier for people to test out the effects and judge it the proposal —TheDJ (talk • contribs) 09:16, 17 November 2016 (UTC)

• I added the CSS code to my user style, and the vertical space difference isn't noticeable in my browser at least. — Eru·tuon 17:27, 20 November 2016 (UTC)

You all know that the official semantics of :-indented text and of the html that it generates is not actually "indented paragraph", right? It is the value / definition data part of a

definition list. Is the proposed wider spacing also appropriate for that meaning? —David Eppstein (talk

) 05:27, 26 November 2016 (UTC)

I assume you know, then, that the mechanism of using <dd>...</dd> to create visual indenting dates back well before the 2001 suggestion of a "semantic web"? This particular bad idea was adopted by the MediaWiki software as a convenient means of visualising threaded discussions, and will require a large effort to bring into line with W3C recommendations. However, this suggestion does not seek to redress that problem: its more modest intent is to help sighted readers see indented "paragraphs" in the same way as they see unindented paragraphs, in an effort to reduce the temptation for editors to leave extra blank lines between posts (which causes an accessibility issue described at

WP:LISTGAP). --RexxS (talk

) 17:17, 26 November 2016 (UTC)

Edit request

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Following the above discussion, I think consensus is clear that making the spacing between indented talk page "paragraphs" (i.e. <dd>...</dd>) and unindented paragraphs (i.e. <p>...</p>) is visually desirable, and may help reduce the temptation for editors to artificially inflate the spacing of indented paragraphs by leaving blank lines which causes inconvenience for users employing assistive technology. Please add the following:

• .ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;}

This will specifically affect only the spacing between indented paragraphs on talk pages. --RexxS (talk) 23:21, 16 December 2016 (UTC)

Done — Martin (MSGJ · talk) 22:00, 17 December 2016 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What? No one is here to complain? In fact no one seems to have even noticed so I judge this to be resounding success. If only all proposals went through so smoothly ... — Martin (MSGJ · talk) 11:25, 22 December 2016 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The PDFlink class is no longer added anywhere by any templates or modules, nor was it ever added by the default implementation of Mediawiki. As such, we should delete the below CSS block.

 /* Change the external link icon to an Adobe icon anywhere the PDFlink class
    is used (notably Template:PDFlink). This works in IE, unlike the above. */
 div#content span.PDFlink a,
 div#mw_content span.PDFlink a {
     background: url("//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif") no-repeat right;
     /* @noflip */
     padding-right: 18px;
 }

--Izno (talk) 03:04, 1 January 2017 (UTC)

Done — Mr. Stradivarius ^{♪ talk ♪} 14:39, 1 January 2017 (UTC)

As previously noted, users sometimes edit an old revision thinking it's the current revision. The mediawiki:editingold warning can be missed, especially on protected pages where there is another warning (see e.g. here). I suggest adding a background color, in a light shade of yellow. This is to differentiate it from the pink background of fully/TE protected pages. And to make the editingold warning match, it would be displayed in yellow. So this would add:

#editingold {
 border: 1px solid #665600;  /* Dark gold */
 background-color: #FFD700; /* Gold */
}
.mw-textarea-oldrev,
.mw-textarea-oldrev + .ui-resizable .ace_content {
  background-color: #FFEF99; /* Light gold */
}

Cenarium (talk) 12:15, 14 January 2017 (UTC)

I'm not entirely certain that we should need to have a different color from a fully/TE protected page. --Izno (talk) 17:11, 14 January 2017 (UTC)

Then admins/TE editors wouldn't be alerted when editing old revisions of a fully/TE protected page. And they may think when editing an old revision of a non-protected page that it just is protected, rather than an old revision. Cenarium (talk) 01:33, 23 January 2017 (UTC)

We have a secondary indicator, which is the bar at the top of the page that says "you're editing old stuff". I don't see how missing it requires us to provide a different color for the edit box. "red" would be sufficient to indicate "hey, are you sure you're editing the page you need to?" --Izno (talk) 11:46, 23 January 2017 (UTC)

I seriously doubt your average Joe who missed the notification among the edit notices, will be able to infer that 'gold background' has any meaning whatsoever. I would suggest making less use of edit notices with 'helpful' advice that people don't read instead. It's a wiki, it's editable and people make mistakes and other people have to correct them. I don't get people's obsession with trying to perfect the behaviour of humans along rigid lines in an open system. That's not the wiki idea. Let's all do a little bit less of cat herding and a little bit more article writing. :) —TheDJ (talk • contribs) 14:54, 23 January 2017 (UTC)

Hi TheDJ. I somewhat agree with what you're saying generally, but in this specific case, I think it's more "why are local CSS hacks needed if there's a real problem in MediaWiki core with users editing old revisions?" I think with most of the local styling in MediaWiki:Common.css, we need to be asking ourselves: is this something that every wiki would experience? If so, the fix likely belongs elsewhere, in my opinion.

I filed phabricator:T160216 about potentially making the user interface clearer when looking at old revisions. Any suggestions from you or Cenarium or Izno or anyone else would be welcome, of course. While I agree with you that we should not expect perfect behavior from users, I think if we see a trend of users making mistaken edits, we need to examine our workflows and try to mitigate against it if possible and reasonable to do so. --MZMcBride (talk) 00:16, 11 March 2017 (UTC)

The top comment in the code uses "markup" wrongly as a verb (which would imply "markupped" and "markupping"!). It should have a space. Equinox ◑ 19:51, 22 February 2017 (UTC)

This is not a hill to die on. :) --Izno (talk) 20:22, 23 February 2017 (UTC)

Hi Equinox. I'm not sure what you're referring to. The top code comment of the current version of MediaWiki:Common.css that I see is "/* Reset italic styling set by user agent */". Where are you seeing the text "markup"? --MZMcBride (talk) 00:21, 11 March 2017 (UTC)

Seven css talk pages redirect here. Based on a search I guess it's about MediaWiki:Mobile.css. PrimeHunter (talk) 00:41, 11 March 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove lines 345, 360–364 and 372–374. {{Navbox}} automatically adds its own header padding now, so the CSS is not required. Thanks, Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:23, 13 March 2017 (UTC)

Question: To save me counting the lines by hand, which specific rules should be removed? Also, I see no recent changes to {{navbox}}, so where has this been discussed, tested and agreed? --Redrose64 🌹 (talk) 14:30, 13 March 2017 (UTC)

@Redrose64: Module:Navbox has been updated per talk page discussion. I used the line numbers for convenience for those using the newer code editor, but the code to be removed is highlighted below. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:00, 13 March 2017 (UTC)

.navbox-title .navbar {
    /* @noflip */
    float: left;
    /* @noflip */
    text-align: left;
    /* @noflip */
    margin-right: 0.5em;
    width: 6em;
}

/* In navboxes, the show/hide button balances the v·d·e links
   from [[Template:Navbar]], so they need to be the same width. */
.navbox .collapseButton {
    width: 6em;
}

.navbox .mw-collapsible-toggle {
    width: 6em;
}

One declaration and two rules each containing one declaration; OK, Done with this edit. --Redrose64 🌹 (talk) 16:58, 13 March 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In light of https://phabricator.wikimedia.org/T155863, the instances of .mw-body here should be .mw-body-content

.mw-body-content sub,
.mw-body-content sup,
span.reference /* for Parsoid */ {
    font-size: 80%;
}

Arlolra (talk) 19:29, 11 April 2017 (UTC)

 Done Go Sharks! Legoktm (talk) 22:30, 13 April 2017 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could MediaWiki:Gadget-WatchlistBase.css please be merged into the site CSS because the gadget says "This loads the base style for the watchlist. Please do not disable this option." If people shouldn't disable it then why make it a gadget that can be disabled? --TerraCodes ^{(talk to me)} 08:43, 25 March 2017 (UTC)

Have you discussed this anywhere? If not, suggest running it past

WP:VPT first — Martin (MSGJ · talk

) 10:06, 25 March 2017 (UTC)

Why not just mark it as a hidden gadget. That's an option now :) —TheDJ (talk • contribs) 12:13, 25 March 2017 (UTC)

I was recently surprised by this gadget preferences line too, it really adds clutter and confusion. See notably Wikipedia:Village pump (technical)/Archive 139#Watchlist button "Mark all as visited" missing.

I thought about using default|hidden, but if for any reason the user had disabled it, I suppose they wouldn't have any way to re-enable it? (apart from preferences full-reset)

Also I would be interested in knowing more about the supposedly unsupported "site" dependency. I just found phab:T147755, but it's about mobile version.

Od1n (talk) 06:28, 11 April 2017 (UTC)

I have disabled this because there doesn't seem to be a specific consensus-backed request yet. — Martin (MSGJ · talk) 07:32, 20 April 2017 (UTC)

I've noticed that the mobile CSS appears to lack the following code:

/* Highlight linked elements (such as clicked references) in blue */
body.action-info .mw-body-content :target,
.citation:target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

This prevents Harvard and other references from being highlighted when the respective author–date citation is clicked (desktop, mobile). Is this deliberate or could the references also be highlighted when clicked on the mobile website? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:02, 27 April 2017 (UTC)

Even though this is a relative uncommon usecase to add to the sitewide styling, I'm proposing to do so, because the current implementation is causing an accessibility problem as well. Feedback welcome —TheDJ (talk • contribs) 12:10, 4 May 2017 (UTC)

This edit request to MediaWiki:Mobile.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could the below code be added to the Mobile CSS between lines 51 and 52?

/* Highlight linked elements (such as clicked references) in blue */
body.action-info .mw-body-content :target,
.citation:target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

This allows Harvard references to be highlighted in pale blue when their corresponding citation links are clicked or pressed. It seems to be missing for no apparent reason. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:40, 4 May 2017 (UTC)

@Jc86035: that's not the style that Mobile uses for this. On mobile, clicking/tapping a reference should bring up a 'toast'/pop-up notification at the bottom of the screen encapsulating the reference. If that doesn't work for harvard references, than we should investigate that and see if we can improve this I think. —TheDJ (talk • contribs) 14:00, 4 May 2017 (UTC)

@TheDJ: Harvard references are currently just section links (example source: [[#CITEREFSmith2005|Smith 2005]], p. 25). I suppose it might have something to do with phab:T154861 but there's no pop-up; they just act like normal anchors. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:11, 4 May 2017 (UTC)

Yes, and this is my concern. Sure, we can add this highlight, but it will create a disjunct in the experience. If we do do this, then I think that we should pick a color from the minerva color palette, and then maybe do a CSS animation where the target is just temporarily highlighted or something, that seems like it would be more in line with the expectations of the mobile platform. —TheDJ (talk • contribs) 14:23, 4 May 2017 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Since this change in the Cite extension: « Don't allow a reference that includes a group name to break in the end of the line »,

Rule #4 in this block can be removed:

/* Prevent line breaks in silly places:
   1) Where desired
   2) Links when we don't want them to
   3) Bold "links" to the page itself
   4) Ref tags with group names <ref group="Note"> --> "[Note 1]" */
.nowrap,
.nowraplinks a,
.nowraplinks .selflink,
sup.reference a {
    white-space: nowrap;
}

So it would become:

/* Prevent line breaks in silly places:
   1) Where desired
   2) Links when we don't want them to
   3) Bold "links" to the page itself */
.nowrap,
.nowraplinks a,
.nowraplinks .selflink {
    white-space: nowrap;
}

Could a sysop apply this change?

Od1n (talk) 22:25, 5 June 2017 (UTC)

@Od1n: You use strange terminology. What you refer to as a "block" is properly termed a rule, and what you refer to as a "rule" is properly termed a selector. See the CSS 2.1 spec, section 4.1.7 and section 5.2.1. --Redrose64 🌹 (talk) 08:44, 6 June 2017 (UTC)

Actually I had read this article on MDN a bit before. I guess I just fell back into some deep-rooted bad habits. Od1n (talk) 11:01, 6 June 2017 (UTC)

Done. If you find more of these, please do report them, it's hard to keep track of them and sometimes we miss some of these. —TheDJ (talk • contribs) 09:47, 6 June 2017 (UTC)

@TheDJ: Your mw-collapsible change had a unanticipated (and IMO negative) impact on enhanced recent changes/watchlist. Could you please make the appropriate fix? I believe you may have been targeting the general case. --Izno (talk) 12:32, 13 June 2017 (UTC)

Can you be more specific than "unanticipated impact" ? —TheDJ (talk • contribs) 13:28, 13 June 2017 (UTC)

Adding the padding caused any page with multiple changes to get padding as well on enhanced RC/WL on the line of the page. It causes the entire line to be indented, creating a non-uniform look in the watchlist. --Izno (talk) 13:30, 13 June 2017 (UTC)

K, lemme figure out something more sustainable. —TheDJ (talk • contribs) 07:30, 14 June 2017 (UTC)

@Izno: dealt with. —TheDJ (talk • contribs) 07:53, 14 June 2017 (UTC)

English Wiktionary has a previewonly class to make content display only in preview mode. It is used, for instance, for messages regarding missing template parameters. (For an example, see wikt:Template:grc-IPA.) This would probably be useful on Wikipedia too. Here's the code that it uses.

.previewonly { display: none; }

#wikiPreview .previewonly { display: inline; }

There is a workaround for making content display only in preview mode: checking to see if the magic word {{REVISIONID}} generates any text. But it would be much easier to simply use a class. Are there any objections? (Has this been considered before?) — Eru·tuon 21:25, 19 June 2017 (UTC)

It has not been considered before as far as I know. I have no objections, and I think that it could solve some problems that have been identified before with the REVISIONID workaround. —TheDJ (talk • contribs) 23:20, 19 June 2017 (UTC)

The evil !important shouldn't be needed, as the more specific selector should always take precedence. Murph9000 (talk) 23:28, 19 June 2017 (UTC)

The style rule was added by Msh210, if he wants to comment. I agree, it should work without !important. — Eru·tuon 05:42, 20 June 2017 (UTC)

The biggest reason we so far have used REVISIONID, is because it does not end up in the actual final HTML when saved, unlike classes like these. While visually hidden, these blobs tend to show up in search engines etc. But REVISIONID trick is not compatible with parsoid, and this can at least be made compatible with parsoid.. I guess both approaches have their problems... —TheDJ (talk • contribs) 14:09, 20 June 2017 (UTC)

Thanks for the ping, Eru·tuon.

I don't recall why I used !important. Likely it's because I wasn't well enough versed in CSS's precedence rules.

I believe that hiding things from a page using display:none is rarely the way to go, since it doesn't (AFAIK) hide things from screenreaders, search engines, and even still a few visual browsers. I seem to think I have maintained that view for a very long time, so am mildly surprised that I added that code in in 2010. Perhaps I had some good reason; I don't know; I don't see anything about in the revision history of my talk page or the archives of Grease pit from that time.

I won't be looking for replies here, so ping me again as needed, please.—msh210℠ 20:03, 24 June 2017 (UTC)

Personally, I don't much like "only in preview mode" things in general. As long as this is limited to actual errors in the page as saved (versus random instructions for editors), though, I don't oppose it. I note that as proposed it won't work in VE, which people should be aware of before making this decision. Anomie⚔ 12:11, 20 June 2017 (UTC)

If anyone cares to do something about it, I've filed two bugs related to the hlist and hlist-separated classes in mobile view. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:32, 2 July 2017 (UTC)

I've proposed at Template talk:Navbox#Border-spacing instead of gutter rows removing the gutter rows from Module:Navbox (sandbox diff), and adding CSS borders in their place at MediaWiki:Common.css (user CSS diff). Looks okay in Firefox, Chrome, IE7 and 8, but if anyone spots a problem please let me know! Matt Fitzpatrick (talk) 06:43, 27 May 2017 (UTC)

How does this play with subgroups, images, columns, groupless rows, and a mix of the above? --Izno (talk) 18:35, 27 May 2017 (UTC)

Good thing I double checked! I thought the CSS worked with all of the Template:Navbox/testcases — but there was one difference I missed. I added more selectors to cover the "border = none" case (new CSS diff). That case renders a .navbox-subgroup without a containing .navbox. All the testcases look okay now. Matt Fitzpatrick (talk) 04:04, 28 May 2017 (UTC)

And good thing I asked. ;) --Izno (talk) 21:17, 29 May 2017 (UTC)

No objection from me (encouragement even). However these two changes will have to be deployed at the exact same time... and even then caching of the pages and jobqueue will likely keep those extra tr's in anonymous content for a while. I suggest prefixing the new css rules with a temporary classname before adding to common.css. Then adding the new classname to the navbox module, wait for everything to settle, then removing the classname from common.css and finally removing the classname from the html again. —TheDJ (talk • contribs) 21:45, 29 May 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please sync from this user CSS (diff). Per TheDJ's caching trick, added a temporary navbox-spacing-temp class, so changes won't be immediately visible. Matt Fitzpatrick (talk) 15:14, 1 June 2017 (UTC)

done —TheDJ (talk • contribs) 15:20, 1 June 2017 (UTC)

Hi

@

Template:Infobox SCOTUS case/courts to not be a navbox (diff). Will that work? Matt Fitzpatrick (talk

) 03:24, 5 June 2017 (UTC)

Works for me, thanks! --MZMcBride (talk) 04:51, 5 June 2017 (UTC)

@Matt Fitzpatrick: Will templates using the navbox class but not {{Navbox}} be affected by this? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:44, 5 June 2017 (UTC)

@Jc86035: Hm, I didn't think of that. If it's a table with two or more rows, yes. I'll start a list of templates using navbox class in my sandbox. Looks like there's a lot of them. Matt Fitzpatrick (talk) 11:50, 5 June 2017 (UTC)

I finished that list of templates using navbox class. (Edited above reply to unlink my sandbox, it's no longer there). Matt Fitzpatrick (talk) 05:14, 7 June 2017 (UTC)

This change is causing problems with succession boxes that are wrapped in {{navboxes}}, see Template talk:Navboxes#Succession boxes: incorrect border. --Redrose64 🌹 (talk) 08:32, 6 June 2017 (UTC)

Why is that even a use case ? Is this abusing the collapsibility of navbox just to hide succession boxes ? That's just... yuck... —TheDJ (talk • contribs) 09:56, 6 June 2017 (UTC)

I don't know, I never do it. I posted here because I was sent there by this note. --Redrose64 🌹 (talk) 10:19, 6 June 2017 (UTC)

The gutterless navbox is still working its way through the cache, but different selectors might work better. When it's time to remove .navbox-spacing-temp, maybe replace the rule with this one? Should be a bit faster for browsers, and not apply to nested tables. Matt Fitzpatrick (talk) 04:00, 7 June 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The above problems are a result of the selectors I wrote hitting tables nested inside navboxes. I went back to the drawing board and think I have a fix. Syncing from this user CSS (diff) keeps the .navbox-spacing-temp mask for now, should fix the problem of borders on nested tables, and should improve browser performance too. Matt Fitzpatrick (talk) 23:30, 7 June 2017 (UTC)

@Matt Fitzpatrick: Not sure if related to the above, but the testcases is displaying all wonky again with irregular row heights. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:37, 15 June 2017 (UTC)

Template:Navbox/testcases? It looks okay to me in Chrome logged in and Firefox logged out. Should I be looking at another browser or testcases page? Matt Fitzpatrick (talk) 20:26, 15 June 2017 (UTC)

@Matt Fitzpatrick: See "Subgroup without all Groups Test" (some of the rows are narrower than the others). I don't have any user CSS enabled. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:28, 16 June 2017 (UTC)

@Jc86035: OK, took a look at it. Group cells have top and bottom padding that list cells do not. So a list cell by itself gets less height than a list cell in the same row as a (padded) group cell. This might be intentional. In the sandbox, I added top and bottom padding to all list cells to match group cells, and that broke other things. Matt Fitzpatrick (talk) 05:46, 16 June 2017 (UTC)

@Matt Fitzpatrick: I think they're supposed to have the same minimum height (see the eswiki version, which uses an older fork of the module). Would fixing this require more CSS? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:57, 16 June 2017 (UTC)

@Jc86035: On eswiki, the list cell has line-height increased to 1.8, so it's only 2 pixels shorter without a padded group cell. I put the same thing in the sandbox here, and it looks OK, though it visibly increases height at "Simple List Only Test" and on any list that wraps to multiple lines. Matt Fitzpatrick (talk) 06:47, 16 June 2017 (UTC)

@Matt Fitzpatrick: Never mind. It looks like there's a CSS rule which adds padding for hlists (line 318, "Adjust hlist padding in navboxes"), so most navboxes shouldn't be affected. On the other hand, some of the navboxes in the testcases don't have the hlist class or list items, so the padding isn't added. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:59, 16 June 2017 (UTC)

Done. —TheDJ (talk • contribs) 08:28, 16 June 2017 (UTC)

It's been 30 days (maximum cache time) since this change was implemented at Module:Navbox. It should now be safe to remove the ".navbox-spacing-temp" masks from the selectors. Matt Fitzpatrick (talk) 04:58, 8 July 2017 (UTC)

done —TheDJ (talk • contribs) 08:02, 8 July 2017 (UTC)

tr + tr > .navbox-abovebelow,
tr + tr > .navbox-group,
tr + tr > .navbox-image,
tr + tr > .navbox-list {    /* Borders above 2nd, 3rd, etc. rows */
    border-top: 2px solid #fdfdfd; /* Must match background color */
}

If you get a chance, could you edit the four selectors as above (deleting the .navbox parents)? With border = none, the module omits the navbox class as a trick to go borderless, for instance Template:Navbox/testcases#Additional tests. In the borderless, no navbox class case, there were still gutter rows to be replaced with this CSS. Matt Fitzpatrick (talk) 07:53, 12 July 2017 (UTC)

Matt Fitzpatrick, done —TheDJ (talk • contribs) 08:19, 12 July 2017 (UTC)

This edit request to MediaWiki:Print.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove !important from the padding: 2px 5px !important; declaration for .infobox td and .infobox th (on line 74 of MediaWiki:Print.css). This is causing rendering problems in {{Routemap}} and {{BS-map}} in printable mode. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:19, 8 August 2017 (UTC)

Question: Why was it put there and could removing it have any other consequences? — Martin (MSGJ · talk) 14:01, 8 August 2017 (UTC)

@MSGJ: It was added by Jon (WMF) at the end of July, along with other infobox rules, probably as part of this. I don't think it would have other consequences, since !important isn't used in the normal stylesheet for infobox formatting, so this would just mimic the regular formatting better. I think some of the other !importants could be removed as well, as they're seldom used in Common.css so they shouldn't be necessary. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:35, 8 August 2017 (UTC)

The !important annotation is a cop-out: it's basically saying, "I can't get this rule to stick, so I'll knock down all the other rules". In most cases, it's better (although probably not as easy) to increase the specificity of the selector. --Redrose64 🌹 (talk) 21:01, 8 August 2017 (UTC)

Done although it was line 81 not 74 I think — Martin (MSGJ · talk) 08:06, 9 August 2017 (UTC)

This seems dangerous to begin with. I made sure it only affects direct children, seems more sustainable. —TheDJ (talk • contribs) 15:09, 9 August 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

For some reason, small amboxes don't have a border, making them seem to blend into the article. Please fix this. Thank you.

@

Jd22292: They show for me, in both Chrome, Firefox and Opera, on pages like 0s BC#5 BC; Florida State Road A1A#Palm Beach County; 2nd Brigade Combat Team, 1st Armored Division (United States)#See also and others in Category:Articles using small message boxes. Which browser are you using, which pages do you see the problem on? --Redrose64 🌹 (talk

) 08:21, 14 August 2017 (UTC)

@

talk

) 18:11, 14 August 2017 (UTC)

Is your browser zoom level set to 100%? Use Ctrl+0 to return to 100% from whatever setting you currently have. Sometimes, zooming out can cause a thin line to become narrower than one screen pixel, hence it doesn't show. As for the left border, that should always be visible - it's 10px wide and   this colour. --Redrose64 🌹 (talk) 23:07, 14 August 2017 (UTC)

Thanks. It might just be my PC then. Sorry for the trouble.

talk

) 23:14, 14 August 2017 (UTC)

We can make <wbr /> work in IE11 and other non-HTML5 compliant browsers by adding this:

wbr:after { content: "\00200B"; }

It adds a zero-width space (​ / ​) after every <wbr />, which effectively achieves the same thing as the <wbr />.

Right now there's only 203 cases of <wbr /> in the mainspace.

However this would mean <wbr /> could replace all of the following:

• {{wbr}} 36 cases
• {{
  zwsp}} 56 cases
• ​ 102 cases
• ​ 405 cases

The issue I want to address is that those 203 cases of <wbr /> aren't doing what they're intended to on IE11, which is still widely used. In the template {{

<wbr /> is the nicest solution which is why I think adding a style rule to make it backwards compatible would be favourable to replacing all instances of it with a template or non-comprehensible unicode.

Rob984 (talk) 14:36, 17 August 2017 (UTC)

@Rob984: do we have any available documentation that shows that this will not negatively effect other browsers ? —TheDJ (talk • contribs) 02:07, 19 August 2017 (UTC)

I have noticed that the common.css contains contains the lines

.mwe-math-mathml-display math {
    display: inline;
}

I would be very happy if someone could explain to me what this actually means. My first interpretation was that it sets the "default" math tags to display="inline" for MathML-capable browsers, but this does not seem to be the case for me. I am asking because I am currently preparing a survey in the German Wikipedia regarding the math formatting and it would be interesting to know what this is good for. Also any relevant discussions about this or future plans here would be very interesting.--Debenben (talk) 08:11, 28 August 2017 (UTC)

The rule was added almost two years ago by Salix alba (talk · contribs), following their suggestion at WikiProject Mathematics. --Redrose64 🌹 (talk) 12:08, 28 August 2017 (UTC)

That is strange. I had a look at Wikipedia:VisualEditor/Feedback/Archive_2015_3#Indentation_for_mathematical_equations where it was first discussed, but those lines are missing. In phab:T111712 they are not explicitly discussed and for me they do not seem to have any effect.--Debenben (talk) 12:55, 28 August 2017 (UTC)

<-- Here's the left margin. Display in-line as default ${\displaystyle {\frac {v_{o}}{a_{e}*l_{o}}}}$ comments added.

<-- Here's the left margin. Display block

$${\displaystyle {\frac {v_{o}}{a_{e}*l_{o}}}}$$

If you inspect those two examples, you'll see the difference between the intended block and inline displays. However, in the second case, you'll also see that the class "mwe-math-mathml-display" applies to a div which does not display and carries the "MathML" for the formula. The div "lives" inside the left-margin of the fallback image. That div has to be inline as does the <math>...</math> that is inside it: hence the "display:inline;" which applies to the 'math' element that you're wondering about. If you are seeing the fallback image, then the div containing the MathML is no more than 1px x 1 px, so having it display block would make virtually no visible difference on your screen. That's probably why you feel it has no effect. I suspect it would have a more noticeable effect if your browser were natively dealing with the MathML, but I could be wrong on that. --RexxS (talk) 16:16, 28 August 2017 (UTC)

Lets see If I can remember what happens.

The default method most editors on most wikis use to produce display maths is to have colon followed by a maths tag.

:<math>a x^2 + b x + c</math>

This is bad markup as it abuses the list indent syntax. There is an option on the math tag to have a display="block" option.

<math display="block">a x^2 + b x + c</math>

This is how VE produces display maths. Ideally, both versions should appear the same as pages are likely to mix the two syntaxes. If the rendering happens with the fallback SVG images then all is good However if MathML is enabled you get something like

Now the reason you don't see anything even in firefox is due to a change discussed at Help talk:Displaying a formula#MathML broken again?. Essentially the MathML display is turned off for firefox, and maybe other clients which can handle the mathml. You can turn the MathML display back on with some CSS. If you do that and remove the .mwe-math-mathml-display math { display: inline; } rule then the VE produced display equations appear center aligned, clashing badly with indented left aligned formula produced by :<math> .

Having the rule in place is not ideal either as it renders the maths as if it was inline producing rather cramped formula which do not match the size of other display math formula on the page. But it is all as bit moot as its hard to actually make the MathML display at all.--Salix alba (talk): 17:06, 28 August 2017 (UTC)

Thank you both for the detailed explaination. The part above the cited code that sets the margins for <math display="block"> displaying it like :<math> I understood. That part is already included in the survey as a suggestion. The .mwe-math-mathml-display math { display: inline; } part I still don't get. If I inspect the elements above I can see the div with the "mwe-math-mathml-display" class living inside the left-margin of the fallback image - that far I can follow. "The diff has to be inline..." why and what does this mean? The way I tried to see an effect was by writing block instead of inline into my custom css and then using the MathML-plugin for firefox to try and spot any difference in behaviour.

And while we are at it: Since using display="inline" for every inline equation can make the source code hard to read, one suggestion in the survey is to make <math> without parameters to be inline and use \textstyle by default. Could something like this be done by changing the CSS in the German Wikipedia?--Debenben (talk) 20:38, 28 August 2017 (UTC)

I just tried the same on my home computer now and got the block equation with MathML being center aligned - I guess that answers the question. Very strange, I must have done something wrong before. I can let you know if I can reproduce it on the other computer next week.--Debenben (talk) 20:58, 28 August 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add:

.toptextcells td,
.toptextcells th {
    vertical-align: top;
}

WP:HTML5 states deprecated HTML valign="top" should be replaced with class="toptextcells", but it's not defined anywhere. Note that you can't just put style="vertical-align:top" to <table> because that would only modify the alignment of the table as a whole and doesn't apply to the content of each cell. Nardog (talk) 15:31, 8 August 2017 (UTC)

Woops. I might have replaced some valign="top" with the CSS style in the table rather than a particular cell. Does adding style="vertical-align: top;" to a table row also not apply it to the content of individual cells? — Eru·tuon 18:47, 8 August 2017 (UTC)

Let's try it:

One	Two Two	Three Three Three	Four Four Four Four	Five Five Five Five Five	Six Six Six Six Six Six	Seven Seven Seven Seven Seven Seven Seven
One	Two Two	Three Three Three	Four Four Four Four	Five Five Five Five Five	Six Six Six Six Six Six	Seven Seven Seven Seven Seven Seven Seven

This works in my browser (Opera 36). --Redrose64 🌹 (talk) 21:51, 8 August 2017 (UTC)

Yes, so .toptextcells tr { vertical-align: top; } would also work.

For the record, .toptextcells is probably an invention at German Wikipedia. Here's the first discussion on this very talk back from 2012. Dozens of articles already use it, sadly to no effect. Nardog (talk) 22:19, 8 August 2017 (UTC)

Neat. It works in my browser (Chrome) too. I could have done the same test.

I like the idea of having a class for this, but toptextcells seems an odd name: it doesn't immediately suggest to me what it does. But since it is already in use, it would be a bit of trouble to go around and change it. — Eru·tuon 01:55, 9 August 2017 (UTC)

Let's not add it here just because it's used in the wild with that name. --Izno (talk) 10:53, 9 August 2017 (UTC)

I was only talking about the question of name, not whether the class should exist. — Eru·tuon 17:33, 9 August 2017 (UTC)

I don't see a whole lot of value here. Where a row needs top-alignment, it's trivial to add it to each row. On top of which, the class isn't really semantic--all it is used for is the styling, rather than telling us something about the row. Why would I need or want top-alignment? I think we should remove the bad guidance at WP:HTML5 instead. --Izno (talk) 10:53, 9 August 2017 (UTC)

We will have TemplateStyles soon, so that we can just fix this for every template that wants it. I therefor don't think there is a good reason to add this to the Common.css right now. —TheDJ (talk • contribs) 14:54, 9 August 2017 (UTC)

I sort of see your point, but this isn't any different from .nowrap in terms of how little it does, is it? Nardog (talk) 14:55, 9 August 2017 (UTC)

Nowrap does carry a bit of semantic intent because we expect nowrap in a certain set of scenarios (namely, a number and a unit name, at the minimum). As a result, it's also got more application. --Izno (talk) 16:43, 9 August 2017 (UTC)

Not done: request disabled due to lack of consensus at this time — Martin (MSGJ · talk) 19:33, 30 August 2017 (UTC)

This edit request to MediaWiki:Print.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Line 9 of Print.css appears to have an error. I believe it should have a comma on the end so that ".ns--1 .ambox" becomes ".ns--1 .ambox," --Prh47bridge (talk) 11:15, 16 October 2017 (UTC) Prh47bridge (talk) 11:15, 16 October 2017 (UTC)

 Done Thank you. Alex Shih^Talk 11:27, 16 October 2017 (UTC)