Jump to content

MediaWiki talk:Common.css/Archive 18

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15Archive 16Archive 17Archive 18Archive 19

Mirror of Wikipedia:template:Tree list/final_branch

see: Wikipedia:Village pump (technical)/Archive_160#Mirror of template:Tree list/final_branch

It was suggested that I ask here:

Hello @PBS: I also have similar question (I'm struggling with similar kind of module). Although I don't know the answer, at least I suppose this is not the template problem, but CSS related. I think messaging to MediaWiki_talk:Common.css would be better. Because "treeview" style in that CSS creating the tree view. I'm paraphrasing PBS's question as follows for other new readers. --Was a bee (talk) 13:24, 2 November 2017 (UTC)
Question
Is it possible to create following kind of tree with CSS?

Branchs are growing not only toward bottom-right, but also toward up-right direction.

................................ ┏ 4. paternal grandfather

.............. ┏ 2. father ┫

.............. ┃.............. ┗ 5. paternal grandmother

1. subject┫

.............. ┃................ ┏ 6. maternal grandfather

.............. ┗ 3. mother ┫

.................................. ┗ 7. maternal grandmother

-- PBS (talk) 17:10, 3 November 2017 (UTC)

Html assumes by default that the content is to be displayed sequentially, so items that are supplied later will normally be displayed below and/or to the right of earlier items. It is possible to use CSS to alter the relative or absolute positions of items, so that in this case they display in a different position from their default using divs and css relative positioning, but there are problems. If later items could be an arbitrary distance higher than the starting point, then there's no automatic way of telling CSS where to place the first item vertically and how big the canvass needs to be. CSS has primitive handling of calculations, so it is rather difficult anyway to compute item positions. If you're prepared to supply a template with the desired x and y coordinates of each item, and the size of the canvass to work on, then CSS can achieve it, but I don't see an obvious way to do that automatically with CSS alone. I think the best bet would be to create a Lua module to handle all of the computations and generate the html/css needed – as Was a bee has been doing. --RexxS (talk) 20:47, 3 November 2017 (UTC)
Thank you for this explanation. It is now much clearer to me. I now understand why my request would be at best complicated to implement. -- PBS (talk) 17:59, 8 November 2017 (UTC)
@RexxS and PBS: I think you are looking for style of {{Clade}} ?? Note that it renders significantly different across various browsers, due to ambiguities in the specifications for HTML and CSS. —TheDJ (talk • contribs) 10:16, 8 November 2017 (UTC)
@TheDJ: Thanks, I hadn't seen that template. I considered the use of table cells to display tree lists, but rejected it as tables really aren't meant to format the display and sometimes screw up when printing, etc. – although I understand the attraction of using them. Also, any solution that relies on nesting templates is going to hit MediaWiki resource limits sooner or later. Nevertheless the {{Clade}} certainly has a lot of features and might well offer a solution to the OP. Cheers --RexxS (talk) 10:43, 8 November 2017 (UTC)
Thank you for the suggestion User:TheDJ. I have explained in detail why this does not help me solve my specific at Wikipedia:Village pump (technical)/Archive 160#Mirror of template:Tree list/final_branch -- PBS (talk)

Protected edit request: #wpSave

Please remove the irrelevant #wpSave style; it's not been applied since OOUIification (the label of the button is already bold).

(Not just doing this myself as there's no urgency; if in future you'd rather I just did it, please say so.)

Jdforrester (WMF) (talk) 00:59, 10 January 2018 (UTC)

 Done @Jdforrester (WMF): for non-urgent things like this a talk notice is nice to document what occurred, thank you! — xaosflux Talk 03:37, 10 January 2018 (UTC)
@Xaosflux: Thanks! Jdforrester (WMF) (talk) 17:28, 10 January 2018 (UTC)

plainrowheaders in mobile

Transferring notice of phab:T183704, which I've closed invalid, since it's a change necessary for mediawiki:mobile.css rather than on the mediawiki side. --Izno (talk) 15:46, 6 February 2018 (UTC)

The most recent edit is currently being thanked instead of the edit you clicked on: phab:T187757. I suggest we hide thanks links until it's fixed: 

.mw-thanks-thank-link {display: none;}

See Wikipedia:Village pump (technical)#Thanks not working. PrimeHunter (talk) 02:15, 20 February 2018 (UTC)

The thanks bug has been fixed. The suggested edit was made before the fix and has now been reverted since the problem should be gone. PrimeHunter (talk) 02:22, 21 February 2018 (UTC)

Extra padding on mobile for ul items generated using plainlist

There seems to be an extra 1 em of padding for <ul> items created using {{plainlist}}. Take a look at Apple Inc.'s infobox on a mobile versus a desktop device.

Here's the CSS for .content ul on en.m.wikipedia.org: 

.content ul {
    list-style: square outside;
    padding-left: 1em;
}

The list-style property gets overridden by line 97 of MediaWiki:Mobile.css, but padding-left doesn't get disabled by anything. On the desktop side though, the list-style is set to none, and margin to 0 by MediaWiki:Common.css (from line 236).

Can someone fix this?

As as side note, I'm not seeing any bold middots (·) or any other separator in horizontal lists either (mobile v. desktop). – Srdjan m (talk) 21:08, 26 February 2018 (UTC)

I noticed this also but was a bit lazy on the point. I would support a change regarding the padding with plainlist. --Izno (talk) 01:17, 27 February 2018 (UTC)
@Srdjan m: this should now be fixed. —TheDJ (talk • contribs) 13:41, 6 March 2018 (UTC)
Yup, looks good. Thanks! – Srdjan m (talk) 13:42, 6 March 2018 (UTC)

Line breaks don't appear in edit summaries without spaces in watchlists / contrib pages

Taken from the beginning of this discussion Wikipedia:Village pump (technical)#Line breaks don't appear in edit summaries without spaces in watchlists / contrib pages: "This diff page shows my long edit summary wrapping so as to not run way off the end of the page. However, this permalink page shows that same edit summary running way off the end of the page, and the same occurs when viewing this edit in my watchlist or contributions page." (see the actual discussion for more information) The user TheDJ suggested there that it has to do with "en.wp's use of mbox tables of the the mw-revision-info" and that I should leave a message here, so here it is. Master of Time (talk) 19:39, 19 March 2018 (UTC)

Did some prelim research. It's best if we reworked the entire message box system to divs eventually.. However, that takes a bit long to execute. Since fmboxes like these are mostly in the administrative spaces, instead i decided to just force them to not use table layout as a first experiment. If this is successful, it might be worth considering converting more of the mbox family CSS and then eventually, we could convert the generated html. —TheDJ (talk • contribs) 13:10, 20 March 2018 (UTC)
@TheDJ: Just FYI, I'm still experiencing wrapping problems with long spaceless edit summaries on my watchlist. Master of Time (talk) 04:43, 27 March 2018 (UTC)
Hmm, seems that FF doesn't like overflow-wrap:break-word on table-cells and just lets them grow, whereas Chrome will restrict the sizing and break.. This is interesting, as we need display-flex with table-cell definitions as fallback for the eventual mbox migration away from tables.. Used break-all for now, which seems to work, but might cause some side effects in line break behaviour.. @Master of Time: better now ? —TheDJ (talk • contribs) 12:15, 27 March 2018 (UTC)
@TheDJ: I don't know why, but it did nothing. I am using Chrome. Master of Time (talk) 22:39, 27 March 2018 (UTC)
@Master of Time: so which browser (and which version of it) do you use ? —TheDJ (talk • contribs) 21:12, 28 March 2018 (UTC)
@TheDJ: My browser is Chrome. If you meant to actually ask about my operating system, it is Windows 10 on my laptop. Despite that, I'm having the same problem on my Windows 7 desktop, also using Chrome. Master of Time (talk) 01:19, 29 March 2018 (UTC)
Sorry, i don't think we can fix this easily. You are welcome to work on it on your own. —TheDJ (talk • contribs) 09:59, 3 April 2018 (UTC)

word wrapping problem from .fmbox

This edit[1] introduced a word wrapping problem across "fmbox" items. The short discussion that brought me here began at Template_talk:Fmbox#word_wrapping_problem. The effect of this can be seen in e.g. edit notices (e.g. Template:Editnotices/Page/Tourette syndrome, but I expect fmbox has a huge scope. Outriggr (talk) 05:24, 1 April 2018 (UTC)

Ping @TheDJ:; Was going to bring up the same thing yesterday; {{fmbox}} is 3/4 used for editnotices. Reading above, did the previous version have a problem in Firefox? There wasn't any issue in chrome atleast in the previous version that I can remember..and the breaking in the middle of a word looks absolutely terrible Galobtter (pingó mió) 09:04, 1 April 2018 (UTC)
Just FYI, ditching the table entirely as TheDJ suggested is probably the only portable way of solving this. HTML has always expanded tables beyond 100% when the content doesn't fit. A single div will give us the same appearance, in fewer bytes, without the wrapping issues. --pmj (talk) 22:49, 1 April 2018 (UTC)
Ditching tables is probably a good idea, but in the interim, I've changed the CSS to apply to fmbox-warning, rather than just fmbox, so that at least it won't affect editnotices and the like. Writ Keeper ⚇♔ 15:06, 2 April 2018 (UTC)
For the record, this is still not an ideal solution; it will still break word wrapping where it shouldn't on pages like this one. Writ Keeper ⚇♔ 15:21, 2 April 2018 (UTC)
Reverted everything. —TheDJ (talk • contribs) 09:58, 3 April 2018 (UTC)

Protected edit request on 2 April 2018

div.mw-lag-warn-normal,
div.fmbox-system {
	clear: both;
	margin: 0.2em 0;
	border: 1px solid #a2a9b1;
	background: #f8f9fa;
	padding: 0.25em 0.9em;
}

doesn't actually do anything. It isn't used, as the comment above it says, in MediaWiki:Readonly_lag; nor does searching for fmbox-system reveal any uses in divs. Similar for mw-lag-warn-normal. It was aded in this diff per this dicussion; Template:No article text doesn't use it either. It should be removed; also creates problems when one tries to use divs instead of tables in Module:message box. Galobtter (pingó mió) 10:53, 2 April 2018 (UTC)

 Done — Martin (MSGJ · talk) 12:41, 10 April 2018 (UTC)

Protected edit request on 25 April 2018

.imagelink_MithulaUK a {
  width:100px;
  height:100px;
  display:block;
  text-decoration:none;
  background-image: url("https://scontent.fhyd2-1.fna.fbcdn.net/v/t1.0-9/15492365_10202747363402568_6380365370535369431_n.jpg?_nc_cat=0&oh=ee836d0e4c5ffaa4500963345e875b8e&oe=5B970CDD") 
}

ParthaSarathiMishra (talk) 03:54, 25 April 2018 (UTC)

 Not done we are not going to change the site-wide css for this. — xaosflux Talk 04:04, 25 April 2018 (UTC)
And we are especially not going to load resources from Facebook's CDN. --Izno (talk) 12:57, 25 April 2018 (UTC)

currently, the {{gallery}} template generates borders around the images, but the <gallery>...</gallery> tag does not.

  • Better with a border
    Better with a border

would it be possible to add a class that enables borders around the images? I did some testing in my own personal common.css and it looks like 

.bordered-images img {
    border:solid #ddd 1px;
}

works, but we could also make it specific to the gallerybox class. thank you. Frietjes (talk) 14:18, 3 May 2018 (UTC)

@TheDJ: Frietjes (talk) 16:56, 5 May 2018 (UTC)
@Frietjes: i'm not against, but we would need to check for all modes, because the extra 2px might cause some of those modes to make incorrect assumptions. —TheDJ (talk • contribs) 13:12, 11 May 2018 (UTC)
@TheDJ: see User:Frietjes/gallery for all modes. I don't see any problems, and it would only be turned on if someone adds that particular class to the gallery tag. unless you are suggesting that we enable it for all galleries, which could be controversial, but would be fine with me. Frietjes (talk) 13:22, 11 May 2018 (UTC)
@TheDJ: Frietjes (talk) 11:46, 24 May 2018 (UTC)

Protected edit request on 26 May 2018

Please add 

.bordered-images img {
    border:solid #ddd 1px;
}

or something more specific but functionally equivalent per the thread above. Frietjes (talk) 14:41, 26 May 2018 (UTC)

 Done Though note that once we have template styles, things like this really should not be in Common.css and thus every single page. —TheDJ (talk • contribs) 19:57, 26 May 2018 (UTC)

July 2018 updates

Hi @TheDJ:, I'm getting "jumping" in Special:Watchlist again, when there is a watch list message, once page load then it is "inserting" the message and shifting the page down - hard to tell if this is "new" but saw you recently made some updates; do you see anything? — xaosflux Talk 17:32, 17 July 2018 (UTC)

it always jumps if you have undismissed messages. However there was a small change regarding the new filters functionality, that I figured I could move, but our notices system is such a mess, that it was causing slight jumps in the old style watchlist even when all messages had been dismissed. I have now reverted this change. —TheDJ (talk • contribs) 20:26, 17 July 2018 (UTC)

Sticky the top bar

Can the top navigation bar please have a position: fixed; added?  Nixinova  T  C  01:57, 20 July 2018 (UTC)

Can you describe what you expect the outcome of this to be more.. — xaosflux Talk 04:12, 20 July 2018 (UTC)
A sticky top bar is implemented in Timeless. You can try switching to that skin. You can also customize your own css if you wish. --Izno (talk) 04:23, 20 July 2018 (UTC)
 Not done That'd dramatically and unexpectedly change the behavior of the website for everyone. As noted above, there are other mechanisms for you to achieve this for yourself without us needing to implement it system-wide. Additionally, the "top navigation bar" can vary significantly for different skins, and would likely not be dealt with here. ~ Amory (u • t • c) 10:45, 20 July 2018 (UTC)

Protected edit request on 27 July 2018

Remove 

/* Style for [[Template:Flowlist]] that Lets lists flow around floating objecs */
.flowlist ul {
	overflow-x: hidden;
	margin-left: 0;
	padding-left: 1.6em;
}
.flowlist ol {
	overflow-x: hidden;
	margin-left: 0;
	padding-left: 3.2em;
}
.flowlist dl {
	overflow-x: hidden;
}

{{flowlist}} now uses WP:TemplateStyles so this is not necessary to be in common.css anymore Galobtter (pingó mió) 12:45, 27 July 2018 (UTC)

@Galobtter: You should fix any uses of it in the wild and probably fix the recommendations to use it without a template. --Izno (talk) 13:12, 27 July 2018 (UTC)
I had fixed the 1 wild use in the article space, have now fixed the two other wild uses outside of article space per your search and the recommendations that I have found, thanks. Galobtter (pingó mió) 13:47, 27 July 2018 (UTC)
 Done LGTM. Sort of surprised the template only has a few score transclusions. ~ Amory (u • t • c) 14:19, 27 July 2018 (UTC)

Noarticletext has some uses

Before change
After change

@TheDJ: There are a handful of pages in search which indicate use of some sort and a number of user pages. I doubt any of those is critical but the class does seem to be referenced. --Izno (talk) 14:03, 31 July 2018 (UTC)

I didn't see anything critical. The main use is primed by an fmbox, which is a table and not a div, the others are mostly gimmick transclusions or other non-critical references. —TheDJ (talk • contribs) 14:08, 31 July 2018 (UTC)
Ah, the CSS isn't all that necessary unless you're transcluding the MediaWiki page for some reason. --Izno (talk) 14:13, 31 July 2018 (UTC)
@TheDJ: I think this change broke the no-article text on Monobook. Here is what I see now; here is what it looked like in the past if I restore the CSS directly. — Earwig talk 01:18, 1 August 2018 (UTC)
@Earwig: Moved into MediaWiki:Monobook.css. Thanks for reporting. —TheDJ (talk • contribs) 06:11, 1 August 2018 (UTC)

Template:Columns to template styles

I'm looking at moving the Template:Columns section to template styles as it is low-volume; does anyone expect issues with these tags being used elsewhere? — xaosflux Talk 17:10, 27 July 2018 (UTC)

Where are those css styles actually used? I'm having trouble finding an example use of them. -- WOSlinker (talk) 18:08, 27 July 2018 (UTC)
I didn't see much (anything?) in the wild for the class in question. There are a few templates which reference the class. --Izno (talk) 18:44, 27 July 2018 (UTC)
There is nothing in that search that matches any of the class names (column , columns-2 , columns-3 , columns-4 , columns-5). Maybe that css just needs removing if not used anywhere? -- WOSlinker (talk) 20:14, 27 July 2018 (UTC)
Huh? The class name is columns. I see hits for Template:Div col, Template:Reflist, Template:Refsubst. Template:Columns-start and Template:Column both show the numbers versions--which should actually be deprecated. (I would guess there are more for the numbers version but my search does not identify those.) --Izno (talk) 20:29, 27 July 2018 (UTC)
Yes there is a class name called columns in Common.css, but that's not the section of Common.css that Xaosflux wants to migrate to template styles. See Template:Columns/styles.css for those classes that are to be moved. -- WOSlinker (talk) 20:48, 27 July 2018 (UTC)
Ah, I was looking at this block, heh, which I think can also be moved: 
/* Reset top margin for lists embedded in columns */
div.columns {
	margin-top: 0.3em;
}
div.columns dl,
div.columns ol,
div.columns ul {
	margin-top: 0;
}

/* Avoid elements from breaking between columns */
.nocolbreak,
div.columns li,
div.columns dd dd {
	-webkit-column-break-inside: avoid;
	page-break-inside: avoid;
	break-inside: avoid-column;
}
--Izno (talk) 21:05, 27 July 2018 (UTC)
But probably not to Template:Columns as that doesn't have any div tags. -- WOSlinker (talk) 21:09, 27 July 2018 (UTC)
Well, yes. --Izno (talk) 21:26, 27 July 2018 (UTC)
As for Maybe that css just needs removing if not used anywhere?, no, it is used; the forms it takes in templates from my review was something similar to columns-{{{column-number|2}}}. --Izno (talk) 21:34, 27 July 2018 (UTC)
It looks like there is a user sandbox for this class which could stand cleaning, but otherwise I don't see an issue removing it here. --Izno (talk) 21:26, 27 July 2018 (UTC)
@Izno: correct, for this section I am only referring to the /* Content in columns with CSS instead of tables (Template:Columns) */ section. — xaosflux Talk 00:00, 28 July 2018 (UTC)
 Done I've moved only the section related to Template:Columns to Template:Columns/styles.css, if any undocumented use is causing an immediate problem feel free to revert. — xaosflux Talk 11:00, 1 August 2018 (UTC)

SiteSub display ('From Wikipedia, the Free Encyclopedia')

Tracked in Phabricator
Task T193215

Every skin seems to have some variant of the following in its specific css: 

/* Display "From Wikipedia, the free encyclopedia" */
#siteSub {
	display: block;
}

Is there any particular reason this shouldn't be moved here, and the skin-specific bits (such as the sizing in monobook/vector) being the only bits actually in the specific skin ones? -— Isarra ༆ 17:19, 2 August 2018 (UTC)

Screw it I'm just going to go ahead and merge them all here. -— Isarra ༆ 21:01, 2 August 2018 (UTC)
You seem to have unintentionally turned it on in Timeless. I don't remember seeing it before. Jc86035 (talk) 15:01, 3 August 2018 (UTC)
I doubt that was unintentional. (And I prefer that it appears!) --Izno (talk) 15:04, 3 August 2018 (UTC)
Yeah, that was precisely what I was trying to do, per phab:T193215. Apparently I need to get a lot better at actually mentioning these things, and finding the tasks to explain why. Apologies for the confusion! -— Isarra ༆ 15:09, 3 August 2018 (UTC)

Editing warning

Hello, I just read the template at the top of the page and think something with ominous connotations (Wikipedia detrimate?) should be highlighted or presented with a warning so it stands out. My concerns are:
Thanks, Otr500 (talk) 19:16, 12 August 2018 (UTC)

Nested hlist bug?

(Moved here from at Module talk:List#Nested list bug?) 

{{hlist|1|2|3|{{hlist|A|B|C}}}}

Expected output (approximated): 1 * 2 * 3 (A * B * C)

Real output:

  • 1
  • 2
  • 3
    • A
    • B
    • C

Is the nested list supposed to go to a new line? This seems like unexpected behavior, especially since I thought the semantic of nesting an hlist inside another was supposed to be a *sublist*. Should it be inserting a newline at the front of the list, too, as it is now? Another user expanded the template HTML and found this: <div class="hlist hlist-separated"><ul><li>1</li><li>2</li><li>3</li><li><div class="hlist hlist-separated"><ul><li>A</li><li>B</li><li>C</li></ul></div></li></ul></div> Because there's no extra newline, it seems to be a CSS issue. They said: "The issue is most likely the extra <div>...</div> inside the list. This could be potentially fixed by removing the <div>...</div> and moving the class specifiers into the <ul>...</ul>. I'm not sure why these need to be in a separate <div>...</div> container. another option could be to add 'display:inline' to the div." lethargilistic (talk) 21:42, 21 August 2018 (UTC)

The original hlist proposal was for a class that could be applied to lists marked up with wiki-markup (;: * #) as well as html elements (dl, ul, ol), so there was an expectation that it would be applied to a container like div where wiki-markup for the list was used. The discussion from 2011 is at MediaWiki talk:Common.css/Archive 13 #Horizontal lists. The hlist template was created some time later and used div containers, quite probably so that they could provide indented lists via a parameter |indent=. Nested lists that apply the hlist class directly to dl/ul/ol do display inline correctly, but as you note the template does not. If the indent parameter is discarded, then the outer div containers could be styled to display inline, or simply removed. Does anyone know how widespread the use of the indent parameter is? --RexxS (talk) 23:22, 21 August 2018 (UTC)
I did an "insource" search for {{[ ]*[Hh]list[^{}]*inline and found 10 articles: Mongol Empire, USS Enterprise (CVN-65), Rugby union in Queensland, New South Wales Suburban Rugby Union, List of compositions by Jean Sibelius, List of Mock the Week episodes, Georgia national football team results, List of 8 Out of 10 Cats episodes, Queensland Country Championships, List of They Think It's All Over episodes. Frietjes (talk) 12:39, 22 August 2018 (UTC)
I guess you intended to type "indent" for the regex, but I get the same 10 results. I think that given the small number of uses, it would be easy to discard the indent parameter for {{hlist}} and simply apply inline styling to its output. The few cases where an indent is desirable could be fixed by use of {{indent}} or {{Block indent}}. Of course, there may be some instances where the horizontal list makes use of the block styling to begin on a newline and there probably isn't a way of predetermining where that happens. Thoughts? --RexxS (talk) 14:24, 22 August 2018 (UTC)
yes, that was a typo. fine with me. would it work to (1) move the classes up to the <ul>...</ul> and remove the div when |indent= is not used and, (2) only add the enclosing div when |indent= is used? Frietjes (talk) 18:14, 22 August 2018 (UTC)
That would be an even more functional implementation; my only reservation is adding complexity to support the hardly-used indent parameter, but I suppose the 10 examples justify it. Why not go ahead and sandbox it? then we can test it a bit before releasing it into the wild. It might give others a chance to pitch in as well. --RexxS (talk) 20:45, 22 August 2018 (UTC)
I went ahead and fixed most of the 10 articles identified in the previous search. I didn't feel as though they really needed to be using the indent parameter, but we shall see if anyone disagrees. this change is an attempt to conditionally remove the outer div. it appears to work, but only if I add |style=display:inline as well. I don't know if we need to worry about anything else being added in the free form |style=. Frietjes (talk) 13:03, 23 August 2018 (UTC)

Protected edit request on 4 September 2018

Remove 

/* When <div class="nonumtoc"> is used on the table of contents,
   the ToC will display without numbers */
.nonumtoc .tocnumber {
	display: none;
}
.nonumtoc #toc ul,
.nonumtoc .toc ul {
	line-height: 1.5em;
	list-style: none none;
	margin: .3em 0 0;
	padding: 0;
}
.hlist.nonumtoc #toc ul ul,
.hlist.nonumtoc .toc ul ul {
	/* @noflip */
	margin: 0;
}

Every instance of use of this class has been replaced with templatestyles using {{nonumtoc}}. Almost every instance of use was in Template:Horizontal TOC; remaining scattered instances (~20) removed by going through an insource search Galobtter (pingó mió) 16:09, 4 September 2018 (UTC)

@Galobtter: can you check over Module:TemplateData if this is still being used there (it could just be obsolete documentation). — xaosflux Talk 16:58, 4 September 2018 (UTC)
Xaosflux, it isn't being used in the module Galobtter (pingó mió) 17:03, 4 September 2018 (UTC)
@Galobtter: thanks for the note, I'll work on enacting this in ~8 hours unless someone else gets to it first. — xaosflux Talk 18:09, 4 September 2018 (UTC)
 Done — Martin (MSGJ · talk) 19:42, 4 September 2018 (UTC)

Remove .transborder

Remove 

/* Pie chart: transparent borders */
.transborder {
	border: solid transparent;
}

The class was used in Template:Twitter Bird, Module:Plotter, Module:Chart & Template:Pie chart/slice. This has now been replaced with inline style in those templates. -- WOSlinker (talk) 22:45, 16 October 2018 (UTC)

{{on hold}} - reviewing. — xaosflux Talk 23:43, 16 October 2018 (UTC)
Added in 2010: MediaWiki_talk:Common.css/Archive_13#Requesting_the_addition_of_a_class_"transborder". — xaosflux Talk 23:59, 16 October 2018 (UTC)
Creation referenced in [[Wikipedia:Village_pump_(technical)/Archive_158#Request:_make_{{Line_chart}}_generate_SVG_rather_than_PNG]]. — xaosflux Talk 23:55, 16 October 2018 (UTC)
insource:/=\"transborder\"/ is clear of use. — xaosflux Talk 23:57, 16 October 2018 (UTC)
Also in MediaWiki:Mobile.css. — xaosflux Talk 00:00, 17 October 2018 (UTC)
 Doing... — xaosflux Talk 00:08, 17 October 2018 (UTC)
 Done @WOSlinker: change made, thank you for your updates. — xaosflux Talk 00:09, 17 October 2018 (UTC)

Chequered background

how do I get rid of the chequered background with transparent images in a <gallery>...</gallery>? for example, the last image in the manned spacecraft gallery. I thought the "nochecker" class would do it, but it appears all that does is set the background colour to white. can we change that rule to turn off the background image as well? Frietjes (talk) 17:12, 13 August 2018 (UTC)

The chequering is a combination of factors, I've reduced them to a minimum set:
this is an unordered list (that's how <gallery>...</gallery> works) but you get the same with nested divs:
If you remove either class, the chequering disappears. It also disappears if you merge the divs retaining both classes, as in <div class="gallerybox thumb">. Somewhere there is a rule defined as follows: 
.gallerybox .thumb img {
    background: #fff url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat;
}
the selector for which reads as "an <img /> element which is a descendant of another element belonging to class thumb which is itself a descendant of another element belonging to class gallerybox". --Redrose64 🌹 (talk) 22:18, 13 August 2018 (UTC)

Redrose64@ this UL has no background:

— xaosflux Talk 00:15, 14 August 2018 (UTC)

And with gallerybox class:

— xaosflux Talk 00:16, 14 August 2018 (UTC)
Hmm never mind, its not really "off" there either, it is white. — xaosflux Talk 00:20, 14 August 2018 (UTC)
You have put full stops before some of your class names. This means that instead of e.g. class thumb, you have class .thumb which is not only a distinct class that is entirely unrelated to thumb, it is not matched by any selector (it cannot be matched, since the full stop has special significance in the selector syntax). --Redrose64 🌹 (talk) 12:37, 14 August 2018 (UTC)
To try to answer the original question: in wiki-markup, you can't turn off the chequering in a <gallery>...</gallery> because you don't have access to an element close enough to the <img /> tag to override the chequered background image. The easiest work-around depends on the fact that the thumb class sets the background white, so you can use a copy of the same image where you have set a white background:
  • Manned space capsules
  • Line drawing of Vostok capsule
    Soviet Vostok capsule
  • Drawings of Mercury, Gemini capsules and Apollo spacecraft, with their launch rockets
    American Mercury, Gemini, and Apollo spacecraft
  • Line drawing of Voskhod capsules
    Soviet Voskhod (variant of Vostok)
  • Soyuz 7K-OK(A) drawing
    1967 Soviet/Russian Soyuz spacecraft
  • Drawing of Shenzhou spacecraft
    Chinese Shenzhou
That leaves the image looking no better nor worse than the other images in the gallery. Not great, but better than the chequered background. --RexxS (talk) 13:21, 14 August 2018 (UTC)

@Redrose64, Xaosflux, and RexxS: it seems like a bad idea that we should be required to upload a white background copy of every image just to remove the chequered background. let's look at the css with comments

 	/* Put a chequered background behind images, only visible if they have transparency.
	'.filehistory a img' and '#file img:hover' are handled by MediaWiki core (as of 1.19) */
	.gallerybox .thumb img {
		background: #fff url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat;
	}
	/* But not on articles, user pages, portals or with opt-out. */
	.ns-0 .gallerybox .thumb img,
	.ns-2 .gallerybox .thumb img,
	.ns-100 .gallerybox .thumb img,
	.nochecker .gallerybox .thumb img {
		background-color: #fff;
	}

to me, it looks like the comments are saying that there is no chequered background "on articles, user pages, portals or with opt-out". that suggests that we should have 

	.ns-0 .gallerybox .thumb img,
	.ns-2 .gallerybox .thumb img,
	.ns-100 .gallerybox .thumb img,
	.nochecker .gallerybox .thumb img {
		background: #fff;
	}

instead. in other words, just change the background-color to background and we can "opt-out" as necessary. is there some reason why this wouldn't work? Frietjes (talk) 14:56, 14 August 2018 (UTC)

@Frietjes: You're right; I was wrong. That does indeed work. You can test it by adding your code to your user css and previewing the following:
  • Manned space capsules
  • Line drawing of Vostok capsule
    Soviet Vostok capsule
  • Drawings of Mercury, Gemini capsules and Apollo spacecraft, with their launch rockets
    American Mercury, Gemini, and Apollo spacecraft
  • Line drawing of Voskhod capsules
    Soviet Voskhod (variant of Vostok)
  • Soyuz 7K-OK(A) drawing
    1967 Soviet/Russian Soyuz spacecraft
  • Drawing of Shenzhou spacecraft
    Chinese Shenzhou
I'd personally prefer background-image: none; rather than resetting all of the background parameters, just in case of unanticipated interactions, but the result is the same. Well worked out! --RexxS (talk) 15:13, 14 August 2018 (UTC)

@Redrose64: Re a class=".thumb" where you say (it cannot be matched, since the full stop has special significance in the selector syntax). It can be matched if you escape it properly, e.g. .\.thumb { border:1px solid red; } or .\2e thumb { border:1px solid red; } Anomie⚔ 00:16, 15 August 2018 (UTC)

It can also be matched if you use the formal attribute selector instead of the shorthand class selector [class~=".thumb"] { border:1px solid red; } but all this is by the by since the class names in the HTML generated by the <gallery>...</gallery> tags do not have full stops in their class names. --Redrose64 🌹 (talk) 19:18, 15 August 2018 (UTC)
please change
	.ns-0 .gallerybox .thumb img,
	.ns-2 .gallerybox .thumb img,
	.ns-100 .gallerybox .thumb img,
	.nochecker .gallerybox .thumb img {
		background-color: #fff;
	}

to 

	.ns-0 .gallerybox .thumb img,
	.ns-2 .gallerybox .thumb img,
	.ns-100 .gallerybox .thumb img,
	.nochecker .gallerybox .thumb img {
		background: #fff;
	}

instead. in other words, just change the background-color to background which will fix the chequered background in House of Medici#Coats of arms. Frietjes (talk) 19:30, 29 October 2018 (UTC)

 Not done: The checkered pattern still existed after a page purge. —CYBERPOWER (Trick or Treat) 22:02, 29 October 2018 (UTC)
Cyberpower678, not sure what you are seeing because this fixes the problem for me. please implement the change again unless it actually broke something. Frietjes (talk) 13:05, 30 October 2018 (UTC)
or, the suggestion by RexxS above to use 
	.ns-0 .gallerybox .thumb img,
	.ns-2 .gallerybox .thumb img,
	.ns-100 .gallerybox .thumb img,
	.nochecker .gallerybox .thumb img {
		background-image: none;
	}
instead if the fix is a browser-dependent. Frietjes (talk) 13:07, 30 October 2018 (UTC)
Redone (but with the background-image reset, which indeed seems more targeted to me). I suspect Cyberpower678 got caught out by the 5 min caching on sitewide CSS. Unless you pass the debug=true param to a page request, you might see the old CSS for up to 5 minutes. —TheDJ (talk • contribs) 15:43, 30 October 2018 (UTC)
TheDJ, maybe that’s what happened. Seeing as this is a site wide change, I cautiously reverted when I saw nothing was changed. —CYBERPOWER (Trick or Treat) 16:03, 30 October 2018 (UTC)
TheDJ, in any event. The checkered background is gone now for me. —CYBERPOWER (Trick or Treat) 16:04, 30 October 2018 (UTC)
looks much better. thank you! Frietjes (talk) 14:36, 31 October 2018 (UTC)

New show class for extendedconfirmed users

Please add to common.css, under .patroller-show,, above .autoconfirmed-show,

.extendedconfirmed-show,.

Then, please create MediaWiki:Group-extendedconfirmed.css with the content 

/* Show hidden items that have class="extendedconfirmed-show". */
div.extendedconfirmed-show,
p.extendedconfirmed-show { 
  display: block !important;
}
span.extendedconfirmed-show,
small.extendedconfirmed-show { 
  display: inline !important;
}
table.extendedconfirmed-show { 
  display: table !important;
}
li.extendedconfirmed-show { 
  display: list-item !important;
}
MediaWiki:Group-extendedconfirmed.css created. — xaosflux Talk 17:04, 10 December 2018 (UTC)

This is in relation with the discussion at Wikipedia talk:Requests for adminship#Non-transcluded RfAs, to hide the "Nominate another user" button from Users who are not extended confirmed, since they cannot transclude any created RfA. I imagine it will find other uses too. ∰Bellezzasolo✡ Discuss 16:42, 10 December 2018 (UTC)

 Done. Also added a link in the comments. Writ Keeper ⚇♔ 17:09, 10 December 2018 (UTC)
Bellezzasolo, Xaosflux, & Writ Keeper. You may be interested in a discussion I opened at the Village Pump as it relates to the new show class. Best, Mifter (talk) 04:28, 23 December 2018 (UTC)

PDF rules (pt 1)

Remove div#content and replace with .mw-parser-output from the following block: 

/* Change the external link icon to an Adobe icon for all PDF files */
div#content a[href$=".pdf"].external,
div#content a[href*=".pdf?"].external,
div#content a[href*=".pdf#"].external,
div#content a[href$=".PDF"].external,
div#content a[href*=".PDF?"].external,
div#content a[href*=".PDF#"].external,

The super-specific selection is causing an issue with styling as described at Help talk:CS1#url-access not working?. (We'll still need to increase the specificity of the selectors in Module:Citation/CS1/styles.css to account for the [href$=".pdf"] selector (probably add .citation) so that the locks will override the PDF icon, but it should be much easier to override without the element#ID selectors.) This remove-replace matches the rules currently in the LESS file loaded by MediaWiki core. (Aside: That particular file loads a different image.) There might be content in #content that should be styled as a PDF, but I'm a big skeptical based on the structure of the page source, and I can think of very few places that absolutely need a PDF link styled as such outside .mw-parser-output.

There are a few examples where the selector .mw-parser-output doesn't catch everything, but those have been illuminated as tasks to work in the TemplateStyles project since TemplateStyles assumes .mw-parser-output. Izno (talk) 20:49, 29 December 2018 (UTC)

To clarify you are asking for the following code to be substituted?
/* Change the external link icon to an Adobe icon for all PDF files */
.mw-parser-output a[href$=".pdf"].external,
.mw-parser-output a[href*=".pdf?"].external,
.mw-parser-output a[href*=".pdf#"].external,
.mw-parser-output a[href$=".PDF"].external,
.mw-parser-output a[href*=".PDF?"].external,
.mw-parser-output a[href*=".PDF#"].external,
And I assume you mean the whole block rather than stopping at the line you have? — Martin (MSGJ · talk) 16:01, 4 January 2019 (UTC)
@MSGJ: Yes, to the first question. It's the first 6 lines of the block in question.
The next 6 lines of the block in question are the below request. --Izno (talk) 18:14, 4 January 2019 (UTC)
 Done — Martin (MSGJ · talk) 21:25, 4 January 2019 (UTC)

PDF rules (pt 2)

Please remove the following block: 

div#mw_content a[href$=".pdf"].external,
div#mw_content a[href*=".pdf?"].external,
div#mw_content a[href*=".pdf#"].external,
div#mw_content a[href$=".PDF"].external,
div#mw_content a[href*=".PDF?"].external,
div#mw_content a[href*=".PDF#"].external

The ID was renamed to mw-content a Long Time Ago at least in modern skins (excluding, well, Modern, apparently). Given its proximity to #content, and given we haven't heard any noise about things not being styled as PDFs with icon, I don't see a need for these selectors.

Regarding Modern, I don't see a need to support Modern because Modern also outputs mw-parser-output, which means this request partially depends on part 1 above. If part 1 doesn't have consensus in its implementation, these should be moved to Mediawiki:Modern.css as the only skin needing these rules. Izno (talk) 20:49, 29 December 2018 (UTC)

 Done — Martin (MSGJ · talk) 21:25, 4 January 2019 (UTC)

Hatnotes on mobile devices

I noticed that there's a rule that defines hatnotes to be in italics but it only works for desktops. I was wondering what rule prevents hatnotes to be in italics on mobile devices. —CaiusSPQR (talk) 03:11, 6 March 2019 (UTC)

@CaiusSPQR: The desktop CSS (MediaWiki:Common.css) has this rule: 
.hatnote {
    font-style: italic;
}
The mobile CSS lacks this rule; so it's not really "prevented" but omitted. --Redrose64 🌹 (talk) 21:18, 6 March 2019 (UTC)
Wait, so MediaWiki:Common.css only applies for desktop? —CaiusSPQR (talk) 21:21, 6 March 2019 (UTC)
I believe so. --Redrose64 🌹 (talk) 13:08, 7 March 2019 (UTC)
@CaiusSPQR: are you referring to the mobile app, the mobile web (en.m.wikipedia.org), or both? — xaosflux Talk 13:45, 7 March 2019 (UTC)
@Xaosflux: I'm referring to the mobile web. Also, if MediaWiki:Common.css only applies to desktop, does the same apply to the user's Common.css page? Does that page defines CSS rules for the mobile website? —CaiusSPQR (talk) 15:47, 7 March 2019 (UTC)
@CaiusSPQR: mobile uses MediaWiki:Mobile.css as its base. phab:T67147 is about making a real "common" page, but hasn't had much work done on it. Hatnotes were last looked at in Mobile by @Jon (WMF): in this edit - see also its summary. Jon, are there good reasons to avoid italics here? — xaosflux Talk 16:07, 7 March 2019 (UTC)
Thanks for the information. —CaiusSPQR (talk) 16:15, 7 March 2019 (UTC)

The NavPic and NavEnd classes are not used in any articles and NavPic just in one template (which may be deleted soon) (NavPic search, NavEnd search) so just wondering if they should be removed from MediaWiki:Common.css, MediaWiki:Print.css & MediaWiki:Common.js? -- WOSlinker (talk) 20:37, 18 March 2019 (UTC)

WOSlinker, sure why not. —TheDJ (talk • contribs) 21:36, 18 March 2019 (UTC)

Here's the changes. Common.css, remove 

div.NavPic {
	background-color: #fff;
	margin: 0;
	padding: 2px;
	/* @noflip */
	float: left;
}

and 

div.NavEnd {
	margin: 0;
	padding: 0;
	line-height: 1px;
	clear: both;
}

Print.css, change 

table.collapsible tr, div.NavPic, div.NavContent {
	display: block !important;
}

to 

table.collapsible tr, div.NavContent {
	display: block !important;
}

Common.js, change 

	// If shown now
	if ( navToggle.firstChild.data === navigationBarHide ) {
		for ( navChild = navFrame.firstChild; navChild !== null; navChild = navChild.nextSibling ) {
			if ( $( navChild ).hasClass( 'NavContent' ) || $( navChild ).hasClass( 'NavPic' ) ) {
				navChild.style.display = 'none';
			}
		}
		navToggle.firstChild.data = navigationBarShow;

	// If hidden now
	} else if ( navToggle.firstChild.data === navigationBarShow ) {
		for ( navChild = navFrame.firstChild; navChild !== null; navChild = navChild.nextSibling ) {
			if ( $( navChild ).hasClass( 'NavContent' ) || $( navChild ).hasClass( 'NavPic' ) ) {
				navChild.style.display = 'block';
			}
		}
		navToggle.firstChild.data = navigationBarHide;
	}

To 

	// If shown now
	if ( navToggle.firstChild.data === navigationBarHide ) {
		for ( navChild = navFrame.firstChild; navChild !== null; navChild = navChild.nextSibling ) {
			if ( $( navChild ).hasClass( 'NavContent' ) ) {
				navChild.style.display = 'none';
			}
		}
		navToggle.firstChild.data = navigationBarShow;

	// If hidden now
	} else if ( navToggle.firstChild.data === navigationBarShow ) {
		for ( navChild = navFrame.firstChild; navChild !== null; navChild = navChild.nextSibling ) {
			if ( $( navChild ).hasClass( 'NavContent' ) ) {
				navChild.style.display = 'block';
			}
		}
		navToggle.firstChild.data = navigationBarHide;
	}

-- WOSlinker (talk) 08:01, 19 March 2019 (UTC)

 Done Galobtter (pingó mió) 15:34, 19 March 2019 (UTC)

Speaking of things that can be removed, I think navbar is probably a good candidate to get shuffled off to TemplateStyles given its limited use. --Izno (talk) 14:37, 18 March 2019 (UTC)

@Izno: better search here but it is indeed fairly limited. That article should get converted to not need a manual css class as well. — xaosflux Talk 00:44, 19 March 2019 (UTC)
This has been on my "todo" list for some time - should also get rid the inline styles from Module:Navbar at the same time. Only issue is, it'll take absolutely forever for all ~8 million transclusions of the template ~13 million transclusions of the module to get updated (and only then can the style be removed from common.css), and since it is used so widely, not like there's a great benefit compared to removing rarely used styles. Galobtter (pingó mió) 13:56, 19 March 2019 (UTC)
@Anomie: Checking in, will it take forever? :)
I think {{Ed}} should probably be integrated with the module in the same way that {{view}} is also before deprecation. --Izno (talk) 15:03, 19 March 2019 (UTC)
It could take a good while for the job queue to get through them all, but probably not forever. ;)

Really I think you'd be good after 30 days because that's the expiry on the parser cache, so even if the job queue or someone's edit or purge didn't get to a page it should be rerendered if viewed after that. Anomie⚔ 22:30, 19 March 2019 (UTC)

Ah, 30 days on the parser cache. Didn't know that. --Izno (talk) 22:54, 21 March 2019 (UTC)

Interface-protected edit request on 22 March 2019

Please create this page with 

/* Show hidden items that have class="checkuser-show". */
div.checkuser-show,
p.checkuser-show {
  display: block !important;
}
span.checkuser-show,
small.checkuser-show {
  display: inline !important;
}
table.checkuser-show {
  display: table !important;
}
li.checkuser-show {
  display: list-item !important;
}

to allow hiding links to Special:CheckUser and Special:CheckUserLog from non-CheckUsers. This is not currently used, but, if and when this edit request is implemented, I will edit / submit edit requests accordingly. See User:DannyS712/sandbox4 for a list of pages where this would be useful. Ping @Salvidrim! due to discussion at Template talk:UTRS-unblock-admin. Thanks, --DannyS712 (talk) 05:08, 22 March 2019 (UTC)

 Done and also added to MediaWiki:Common.css and MediaWiki:Mobile.css —TheDJ (talk • contribs) 09:07, 22 March 2019 (UTC)

TemplateStyles live now

TemplateStyles is live for sometime now. I think you should update MediaWiki:Mobile.css, don't you think? --CaiusSPQR (talk) 20:42, 17 March 2019 (UTC)

@CaiusSPQR: Most people who follow this page are aware that TemplateStyles are available. However, we are also aware that much of our CSS has legacy uses not using a template. That means it is not a trivial task to update our global CSS (Common, Mobile, and the skins). You are welcome to help figure out what needs to be done and subsequently to do it. --Izno (talk) 13:29, 18 March 2019 (UTC)
@Izno: Look, I wasn't trying to impose anything. It's just that there were some comments in the code reminding to move the code to TemplateStyles, so I thought you might have forgotten. I was just trying to help. —CaiusSPQR (talk) 21:42, 25 March 2019 (UTC)
You couldn't impose anything even if you wanted. :) --Izno (talk) 21:52, 25 March 2019 (UTC)
I wasn't commenting on whether I could impose something or not — I just said it was not my intention to try to impose anything. :) —CaiusSPQR (talk) 21:58, 25 March 2019 (UTC)
And we have actually moved many styles to TemplateStyles, but as Izno points out this is not trivial. If you see a specific style, especially one that is limited to a specific template or small batch of related templates, you can start building the template styles in advance - then we can test and plan a cut-over from the core css files. — xaosflux Talk 13:37, 18 March 2019 (UTC)

Global user groups

Question: Template:CSS and JS MediaWiki messages shows user-group wide CSS and JS pages for local user groups, but are there also such pages that would apply to global user groups that are active locally (and can be created here, as opposed to meta?) Specifically, {{Unblock-un}} and {{Unblock-spamun}} both have "rename user" links that only work for global renamers, stewards, and WMF Support and Safety, and I wanted to know if they could be hidden. Thanks, --DannyS712 (talk) 03:30, 5 April 2019 (UTC)

Sounds more like we don't really need that link on those templates... — xaosflux Talk 03:49, 5 April 2019 (UTC)
@Xaosflux: maybe, but as someone who would never use them I can't speak to their usefulness. --DannyS712 (talk) 03:50, 5 April 2019 (UTC)
Many of those who patrol CAT:RFU are global renamers and the link would seem convenient for them. Galobtter (pingó mió) 08:50, 5 April 2019 (UTC)
If someone wants them keep it, this is such an edge case that building hiding classes seems a bit unnecessary though. Practically, the only global group users that would process an on-enwiki request from that template would be global renamers as well. — xaosflux Talk 11:03, 5 April 2019 (UTC)

Italic text for dfn

Hi all

The Common.css has a section at the top that says: 

/* Reset italic styling set by user agent */
cite, dfn {
  font-style: inherit;
}

But the MediaWiki:Mobile.css stylesheet lacks this. This means that dfn tags appear in plain text on desktop, but in italic in mobile view. See User:Amakuru/Dfn for an example - when you view in desktop the words are plain, and in mobile they are italic. The page has one plain dfn tag, and one where it is appearing in the {{cuegloss}} template (that's where I spotted this issue). Would it make sense to add something like the above line to Mobile.css? Thanks  — Amakuru (talk) 07:04, 25 April 2019 (UTC)

@Jon (WMF): ^? --Izno (talk) 16:00, 25 April 2019 (UTC)
Besides the ping, <dfn> is rare or non-existent outside of templates at this time, so another way to deal with the problem is to add TemplateStyles. I think given that we're resetting the elements across-the-board, it makes sense to add this CSS to the mobile sheet as well. --Izno (talk) 16:01, 25 April 2019 (UTC)

Fix for miscoloring of Special:Contributions

Please can an interface admin add the following rule as discussed at Wikipedia:Village pump (technical)#Weird highlighting of some of my contributions, as a temporary fix until the issue can be resolved server-side. 

.flaggedrevs-unreviewed {
	background-color: inherit !important;
}

-- the wub "?!" 15:01, 24 June 2019 (UTC)

I bet that would disable the coloring where it's intended too. And some edits of pending-changes-protected pages are in blue. I suggest the following:
.mw-contributions-list .flaggedrevs-unreviewed,
.mw-contributions-list .flaggedrevs-color-1 {
	background-color: inherit !important;
}
Nardog (talk) 15:06, 24 June 2019 (UTC)
No need, it's been fixed now. Reedy (talk) 15:29, 24 June 2019 (UTC)

Scroll tables on small screens

On the default mobile skin, table styles are configured such that they scroll when space is unavailable. I think these styles would be better kept on wiki and provide a useful default behavior for tables on all skins and on all devices. Something like: 

#bodyContent table {
  /* Provide a horizontal scrollbar to tables when screen space is unavailable. */
  overflow-x: auto;
  display: block;
  /* Table widths can be specified but should be limited by available screen space. */
  max-width: 100%;
}

Perhaps these styles could be even further improved with screen width media queries.

I think this change in default functionality is reasonable at it's already in effect for the majority of pageviews. Just as it is now on mobile, templates that wish to opt-out would be the exception to the default and specify an override using TemplateStyles.

-- Niedzielski (talk) 21:53, 7 June 2019 (UTC)

Would need restricting to class wikitable to avoid messing up navboxes. -- WOSlinker (talk) 11:22, 18 June 2019 (UTC)
Do you have some examples in mind you're concerned about? It's still possible to specify any width, including 100%, for a table and allow overflow to scroll gracefully within the bounds of the table instead of the entire page. I think that presenting the page's content within the constraints of the window is paramount and overflow should be confined to the smallest element possible with hopefully nearly all cases handled by the above rules. -- Niedzielski (talk) 16:47, 6 July 2019 (UTC)
This would need to be tested on the responsive versions of Monobook and Timeless IMO. Also, I'm not sure we should encourage large tables anyway. --Izno (talk) 19:22, 18 June 2019 (UTC)
Large tables are necessary in some cases. I think we should define a good overflow default because the scrolling will happen for the whole page (instead of just the table) if we don't. MonoBook appears to take the approach of scrolling all page content at once which doesn't seem ideal but at least would allow the skin chrome to remain stationary. -- Niedzielski (talk) 16:47, 6 July 2019 (UTC)

Styling for offline content

While working on VideoWiki, a need arose to embed content that was only visible when the content was being viewed offline, via Kiwix. The editors at WikiProject Med create a lot of content that is distributed throughout the world to places where internet access is poor or non-existent, and it is useful to be able to insert content especially for those readers.

I produced a simple template, Template:OnlyOffline, which uses Template:OnlyOffline/styles.css to hide content marked up with the class "onlyoffline". The idea was that Kiwix will also read from MediaWiki:Offline.css which will now display the content when being viewed offline. Unfortunately, TemplateStyles adds its css node after the common classes in every case, and even the horrible !important doesn't allow MediaWiki:Offline.css to override the TemplateStyles for reasons that I haven't yet got to grips with.

My colleague Kelson, who does all the Kiwix work, has suggested that we move the code in Template:OnlyOffline/styles.css to MediaWiki:Common.css. That's a rather retrograde step, I agree, but it's an unusual case, and this may be the only way to resolve the problem.

So, I'd like to gain consensus that the following code be added to MediaWiki:Common.css: 

/* hide content of class when online */
/* content is displayed when offline via [[MediaWiki:Offline.css]] */
.onlyoffline {
	display:none;
}

If anybody has solved similar issues without giving up on TemplateStyles and/or can provide a better solution, I'd be happy to adopt that instead. Otherwise I'd be grateful for support for inclusion of this new class. Cheers --RexxS (talk) 14:38, 10 July 2019 (UTC)

  • @RexxS: if you think that class computation to the final output is malfunctioning, have you opened a phab ticket you can share? — xaosflux Talk 14:51, 10 July 2019 (UTC)
  • RexxS, please don't add content that is selectively shown by CSS (as opposed to selectively hidden). Not all user-agents use it, and it often gets indexed by search engines accidentally (and it's an accessibility issue). We generally only do this for 'admin' actions etc that are hidden inside Wikipedia namespace etc, or for templates which should be temporary anyways.. Any content should always be non-harmful when the CSS is not present (see also why you should never expend collapsible to work etc when writing a page). —TheDJ (talk • contribs) 14:51, 10 July 2019 (UTC)
    • If this is something you 'need', the only alternative I would support is something like; using comments to wrap a syntax that your user-agent can specifically recognise and transform into whatever it needs. This way other user-agents will happily ignore it. —TheDJ (talk • contribs) 14:56, 10 July 2019 (UTC)
  • I'd recommend naming the class offlineonly rather than onlyoffline for consistency with existing classes like printonly. Could you give an example of where it would be necessary to show certain content only to offline users? --Yair rand (talk) 21:05, 10 July 2019 (UTC)
    • An example is here. Basically we have a version of our offline medical app[2] that contains videos. This is the version we ship in Internet-in-a-Box. It has not been updated in more than a year as the EN community requested that videos be collaboratively editable before we look at including summary videos. Well we are working on this issue at WP:Videowiki there is still a lot of work to do. Doc James (talk · contribs · email) 16:53, 12 July 2019 (UTC)

Add an option to not include parenthesis for .hlist sub-lists and instead separate the items with a bullet

Could a option be added to .hlist to not include parenthesis for sub-lists and instead separate the items with a bullet? This is the code I'm referring to: 

/* Add parentheses around nested lists */
.hlist dd dd:first-child:before, .hlist dd dt:first-child:before, .hlist dd li:first-child:before,
.hlist dt dd:first-child:before, .hlist dt dt:first-child:before, .hlist dt li:first-child:before,
.hlist li dd:first-child:before, .hlist li dt:first-child:before, .hlist li li:first-child:before {
	content: " (";
	font-weight: normal;
}
.hlist dd dd:last-child:after, .hlist dd dt:last-child:after, .hlist dd li:last-child:after,
.hlist dt dd:last-child:after, .hlist dt dt:last-child:after, .hlist dt li:last-child:after,
.hlist li dd:last-child:after, .hlist li dt:last-child:after, .hlist li li:last-child:after {
	content: ")";
	font-weight: normal;
}

The use-case where I'd like to use it is in Template:Horizontal TOC and List of The Simpsons episodes, where the parenthesis just make the ToC (a) longer and (b) much more messier, with no really added value. --Gonnym (talk) 13:36, 12 July 2019 (UTC)

@Gonnym: if this issue only occurs with some special templates, are you not able to achieve your results with template styling? — xaosflux Talk 13:44, 12 July 2019 (UTC)
I have very limited knowledge with CSS and when I raised the issue at the template page, I was told that it can only be done if .hlist changes, which is why I asked here. If this can be done in another way that would be great, but I'll need some help to point me in the right direction. --Gonnym (talk) 13:52, 12 July 2019 (UTC)
@Frietjes: have you already looked in to this - expanding the common.css for a limited use is something we don't love doing. — xaosflux Talk 13:58, 12 July 2019 (UTC)
This is not particularly true. Make your own class with its own declarations and include WP:TemplateStyles. Heck, actually, you can make a selector like .myTemplate .hlist... and then your changes only impact the template of interest. --Izno (talk) 14:50, 12 July 2019 (UTC)
(You would need to add another class to the selector if you intend it to be optional, and then include the class optionally in the output of the template, but this is also trivial.) --Izno (talk) 14:51, 12 July 2019 (UTC)
If <div class="hlist horizontal-toc is the template code, how would I do that? <div class="{{#if: {{{no_parenthesis|}}} | no-parenthesis | hlist }} horizontal-toc with "no-parenthesis" being added to the TemplateStyle? --Gonnym (talk) 15:08, 12 July 2019 (UTC)
<div class="{{#if: {{{no_parenthesis|}}} | no-parenthesis}} hlist horizontal-toc. The declarations you make with the no-parens selector should only override the hlist styles where necessary--you don't need to fully duplicate all of the hlist CSS. I also would use something like 'horizontal-toc-no-parentheses' as the class name to avoid possible overlap elsewhere, but that's an aside to the point. --Izno (talk) 15:22, 12 July 2019 (UTC)
I think I got it to work. Would you look at the CSS and see if I didn't do anything to mess something else? --Gonnym (talk) 15:54, 12 July 2019 (UTC)
That looks correct. You don't need the empty rule at the top. You shouldn't need to invoke .hlist on the rules since these are more specific in their selectors. --Izno (talk) 17:56, 12 July 2019 (UTC)
Thanks for the help Izno! Much appreciated! --Gonnym (talk) 18:45, 12 July 2019 (UTC)

Interface-protected edit request on 19 July 2019

Please remove 

/* For template documentation */
/* TemplateStyles */
.template-documentation {
	clear: both;
	margin: 1em 0 0 0;
	border: 1px solid #a2a9b1;
	background-color: #ecfcf4;
	padding: 1em;
}

I have added the CSS to the module itself (not using TemplateStyles though) - see Special:Permalink/906971298#Moving CSS. Thanks, --DannyS712 (talk) 15:21, 19 July 2019 (UTC)

Oppose: discussion at Template talk:Documentation. --RexxS (talk) 16:57, 19 July 2019 (UTC)
 Not done as there is an ongoing discussion right now, feel free to reactivate when resolved. — xaosflux Talk 17:20, 19 July 2019 (UTC)
Quick note that once this is reimplemented in TemplateStyles per the discussion there, you'd have to wait a few days or so for all the pages that transclude the module to update before the styles can be removed from common.css Galobtter (pingó mió) 20:54, 19 July 2019 (UTC)

Cleaning up message box CSS

I made Special:PermaLink/906004310 (Module:Message box/sandbox) + Special:PermaLink/906003901 (Module:Message box/configuration/sandbox) + Template:Cmbox/styles.css, Template:Ombox/styles.css, Template:Imbox/styles.css, Template:Fmbox/styles.css, Template:Ambox/styles.css, Template:Tmbox/styles.css, Module:Message box/styles.css (All need to protected before we move forward). And now we need to replace the sandbox modules with the main ones and then remove 10KB of not needed CSS from here. That would save hundreds of Terabytes in network (even after minification and compression) per month, not to mention the CPU usage in the servers. I did a similar thing in wikidata, works fine. Is anyone willing to help? ping User:Galobtter per history 23:55, 12 July 2019 (UTC) — Preceding unsigned comment added by Ladsgroup (talk • contribs)

@Ladsgroup: Have you checked to verify that all uses of the CSS in Common.css are invoked only from within the box templates? Also, please consider storing the CSS in the module space since that is where the HTML originates. --Izno (talk) 02:14, 13 July 2019 (UTC)
@Ladsgroup:
  1. cmbox is missing it's first rules.  Done
  2. The compact ambox rules were forgotten
  3. I have no idea if noflip actually does anything in templatestyles (and if this affects transferability to other wikis for that reason).
  4. fmbox is used in editnotices and other MediaWiki messages, we should verify if they even work there (aka is there mw-parser-output wrapping in editnotices..). Suggest leaving these in MediaWiki:Common.css for that reason
  5. There is one css line with .skin-vector etc would break in templatestyles. Move it to Vector.css ??
  6. Izno's point that there might be usages of the classes outside of the module.. We'll have to find those.
That's the potential problems i can spot.—TheDJ (talk • contribs) 14:36, 13 July 2019 (UTC)
Oh, there is another issue. This breaks the stackability of amboxes, as there is now two link elements before every ambox, and that breaks the sibling selector table.ambox + table.ambox . So that should have a variant like: table.ambox + link + link + table.ambox.. We should probably sprinkle a comment next to the module that inserts templatestyles to make sure future editors don't accidentally break that. —TheDJ (talk • contribs) 14:50, 13 July 2019 (UTC)
Attempting to undo these edits indicates no output of mw-parser-output, and that's without edit notices. Anomie? --Izno (talk) 15:01, 13 July 2019 (UTC)
mw:Extension:TemplateStyles#Caveats, first bullet? You may have to manually add a wrapper div for messages used outside the content area if TemplateStyles is to apply. Anomie⚔ 18:29, 13 July 2019 (UTC)
User:TheDJ Regarding 1, it's done. Thanks for catching. Regarding 2, Are you sure it's used? I couldn't find it in the module. 3) I don't know either :/ fixing it should be on hands of the person moving it I think 4) It seems they are wrapped, so it's fine I guess 5) I can't do it, I don't have access, can you? 5) yeah, we should check. I can help as much as possible if I'm not alone. 6) I'm not sure but I think they get deduplicated I think, I don't know if I understood you correctly. Ladsgroupoverleg 19:42, 13 July 2019 (UTC)
It is not a question of duplication but simply that we should not regress on display of boxes using the styling but not using the templates which would otherwise wrap those styles. --Izno (talk) 19:51, 13 July 2019 (UTC)
Er, did you misnumber there? with duplicate 5s and a 6 rather than 7? --Izno (talk) 19:54, 13 July 2019 (UTC)
Yup, my bad, sorry. Ladsgroupoverleg 23:32, 13 July 2019 (UTC)
As for skin-vector, that is allowed in TemplateStyles. See the same link that Anomie provided, last bullet of #Caveats. --Izno (talk) 19:51, 13 July 2019 (UTC)
It seems we can't do the compact ambox. Adding them errors with "Invalid or unsupported value for property list-style-image at line 87 character 20" Ladsgroupoverleg 23:35, 13 July 2019 (UTC)
If you're referring to what's currently at lines 876–886 of MediaWiki:Common.css, you should be able to if the images are uploaded to Commons rather than trying to use url(/w/skins/etc...). You'll probably also have to drop the IE<11 hack from line 885. Or if the skin images are really needed, you could file a Phabricator task to add the appropriate URLs to the config. BTW, it seems the MonoBook image being used there was deleted in April. Anomie⚔ 16:43, 14 July 2019 (UTC)

I would keep compact ambox for now, what do you think if we put the new styles into the module and slowly and after checks remove the classes from here? Ladsgroupoverleg 19:21, 15 July 2019 (UTC)

Ladsgroup, i think that is the best approach. Just implement and then remove css one template family at a time. Unfortunately, I can't help with that, as I no longer have the required editing rights. — Preceding unsigned comment added by TheDJ (talk • contribs) 07:28, 16 July 2019 (UTC)
I totally understand :( Anyone else willing to help? Ladsgroupoverleg 13:26, 20 July 2019 (UTC)
Will look about doing this after finishing #Hatnote CSS to TemplateStyles. Some notes from quick investigation now and when I previously looked at this:
  • noflip is a function of CSSJanus, [3] would suggest that TemplateStyles does indeed work with that (if it noflip didn't work, that certainly would be a clear bug in TemplateStyles)
  • I think all fmboxes should be wrapped in 
    <div class = "mw-parser-output">
    since they are almost always used in system messages. Quite a few editnotices use non-fmbox Message boxes too. For that the best solution I think is to make Template:Editnotice load wrap all editnotices in mw-parser-output. Apart from those, 12 system messages use Module:Message box, and some editintro messages, [4], which can be manually fixed to use mw-parser-output as necessary.
  • Then here would be fixing the uses outside of the templates.
  • As TheDJ says, would need to fix the css for the presence of two link elements before every ambox.
  • As Izno says, the css should really be at say Module:Message box/ambox.css, since you can use ambox outside of Template:Ambox.
  • Would need to wait 30 days for all parser outputs to be invalidated after updating Module:Message box, so that all pages with message boxes load the styles. Galobtter (pingó mió) 00:10, 21 July 2019 (UTC)

Let's keep a centralized progress checklist. —TheDJ (talk • contribs) 22:06, 23 July 2019 (UTC)

Hatnote CSS to TemplateStyles

Per a search, the only uses of the class hatnote outside of Module:Hatnote are these and these. These are mostly modules that use it to show a message in preview for which I've created Module:Preview warning message. So once those modules are updated to use Module:Preview warning message, then we can update Module:Hatnote from Module:Hatnote/sandbox to use Module:Hatnote/styles.css, and after waiting, can remove the hatnote styles from common.css. Posting here in case anyone knows if there is anything else that would need fixing. (regarding interface messages, would just have to fix MediaWiki:Wantedpages-summary. There's also a couple of edit notices using {{hatnote}}, but I think all edit notices should be wrapped in mw-parser-output by changing Template:Editnotice load) Galobtter (pingó mió) 00:09, 21 July 2019 (UTC)

Template:Editnotice load has been updated. — xaosflux Talk 22:08, 23 July 2019 (UTC)
  • Honestly, all those module uses of hatnote look like misuses, and I would advocate instead for their own CSS rather than loading the entire hatnote template and styles. Hatnotes are for navigation, not for errors. <div class="template-preview-error error"> would be vastly more appropriate. --Izno (talk) 04:47, 26 July 2019 (UTC)

/w/skins/Vector/images/bullet-icon.png and /w/skins/MonoBook/resources/images/bullet.gif are not part of Mediawiki code base

Hi, /w/skins/Vector/images/bullet-icon.png is not part anymore of mediawki codebase. At least it leads to a HTTP 404... but this is still part of Common.css. This should be removed or replaced. Kelson (talk) 08:15, 16 July 2019 (UTC)

Same problem with /w/skins/MonoBook/resources/images/bullet.gif Kelson (talk) 08:16, 16 July 2019 (UTC)
  • Looks like this is left over from 4 years ago - as there is no file, should be safe to remove - does anyone have any other comments on this? — xaosflux Talk 15:08, 16 July 2019 (UTC)
    Anomie actually noted the vector item in the ambox discussion above. That one should be removed. However, there is a replacement for the Monobook one at '/w/skins/MonoBook/resources/images/bullet.svg'. Speaking of which, that one should probably select for skin-monobook. --Izno (talk) 16:27, 16 July 2019 (UTC)

Thanks for removing bullet-icon.png... but what about bullet.gif? Do we (should) have a phabricator ticket about that? Kelson (talk) 15:20, 21 July 2019 (UTC)

No, should use bullet.svg instead. Galobtter (pingó mió) 20:20, 21 July 2019 (UTC)
Why you don't fix it then? Kelson (talk) 06:47, 24 July 2019 (UTC)

/w/skins/MonoBook/resources/images/bullet.gif is not part of Mediawiki code base

Hi, /w/skins/Vector/images/bullet-icon.gif (only the png problem has been fixed in previous discussion) is not part anymore of mediawki codebase. At least it leads to a HTTP 404... but this is still part of Common.css. This should be removed or replaced. Kelson (talk) 12:29, 3 August 2019 (UTC)

Change 

	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.gif);

to 

	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.svg);

in the 

.compact-ambox table .mbox-text-span {
	display: list-item;
	line-height: 1.5em;
	list-style-type: square;
	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.gif);
}

per the above discussion. This is the more conservative change. I expect per the ambox template stylization that these will eventually leave Commons.css, and possibly be selective for other skins, but that can be Down The Road. --Izno (talk) 19:09, 3 August 2019 (UTC)

On an aside, I'm pretty sure the reason that block does not restrict itself to a certain skin is so that all the skins have a fallback which includes some styling. Otherwise, it would be as-if Modern or Timeless had no styling at all on the point. --Izno (talk) 19:12, 3 August 2019 (UTC)
Yeah; and modern uses the same bullet image too. Galobtter (pingó mió) 01:10, 5 August 2019 (UTC)
 Done — xaosflux Talk 14:29, 4 August 2019 (UTC)

Avoid elements breaking between columns

I noticed at Atlanersa#Sources that sources are breaking across columns when they are in a definition list. Seems there's a typo in line 115 and it should be changed from 

div.columns dd dd {

to 

div.columns dd {

-- the wub "?!" 23:10, 13 November 2019 (UTC)

Definition lists are deprecated and should not be supported. The correct change is to fix the page in question by switching to an unordered list. --Izno (talk) 23:26, 13 November 2019 (UTC)
That said, I think that's the correct fix. --Izno (talk) 23:33, 13 November 2019 (UTC)
Thanks for fixing that article. I agree that unordered lists should be preferred as they are more semantically correct, and wouldn't object to just removing the broken rule. the wub "?!" 23:16, 17 November 2019 (UTC)
I don't think removing the rule is correct, since the selector applies to templates which are not just this use. --Izno (talk) 23:21, 17 November 2019 (UTC)

@The wub: I've applied the change. Please let me know of any issues — Martin (MSGJ · talk) 20:48, 29 November 2019 (UTC)

See also: Module talk:Sports table/Archive 1 § Navbar linebreak in Safari 11.1.1

About a year ago, I noticed that the tables at 2018 FIFA World Cup looked ugly because Safari would insert a line break after the ul {{navbar}}. Now, .navbar ul {…display:inline-block} fixes this; so, shouldn't this be the case? inline-block is accepted by IE8+, so we should be fine unless someone is using Wikipedia on a very old POS system. Sceptre (talk) 17:48, 16 September 2019 (UTC)

@Sceptre: is this a single-page issue? Can it be fixed more locally with a template style? — xaosflux Talk 03:20, 29 September 2019 (UTC)
It happens when Module:Sports table is invoked with an option for navbar links, and I suspect a lot of other places where the navbar module is invoked with the option for brackets. At that point, it becomes a case of pick-your-poison where you do the edit, either on Common.css or Module:Navbar. I imagine the least intrusive (and more sensible; it doesn’t make sense to declare a style in a .css then locally override it on every instance) thing to do would a Common.css edit, ironically. Sceptre (talk) 04:28, 29 September 2019 (UTC)
Sceptre, to confirm, you want to change
.navbar ul {
display: inline;
white-space: nowrap;
}
to
.navbar ul {
display: inline-block;
white-space: nowrap;
}
?
I think it would be useful if someone else confirmed the issue in Safari and that the above fixes it (since I have no access to a machine running Safari). Galobtter (pingó mió) 23:07, 10 October 2019 (UTC)
I do indeed see this on Safari on my machine, and moving to inline-block does indeed solve it. I'm not entirely sure why this is all here and not in the modules, but w/e. I haven't tested or checked if it mucks anything up elsewhere, though. Why does Safari treat this differently than other browsers? ~ Amory (u • t • c) 18:27, 13 October 2019 (UTC)
Yeah, I never got around to moving the styles to the module from common.css. Maybe I'll do that now. https://github.com/mathjax/MathJax/issues/1982 seems to be the same issue? Galobtter (pingó mió) 18:59, 13 October 2019 (UTC)
Consider whether a slight bug is relevant. --Izno (talk) 02:37, 11 October 2019 (UTC)
IE8 is in the basic support category, though, so maybe not a huge issue. ~ Amory (u • t • c) 15:31, 13 October 2019 (UTC)
I have made the change. Sceptre please confirm this is working as intended — Martin (MSGJ · talk) 20:42, 29 November 2019 (UTC)
@MSGJ:: Looks like it's fixed. Thank you. :) Sceptre (talk) 16:07, 2 December 2019 (UTC)

Bulleted list – line spacing problem

Any comments?--Hildeoc (talk) 16:26, 19 November 2019 (UTC)

So, lists have a slight margin on top, even sublists. The last discussion on this I could find was here from 2017. I've also always found the spacing in sublists to look strange, would adding the rule .mw-content-ltr ul ul { margin-top: 0px; } maybe work? – Thjarkur (talk) 16:58, 19 November 2019 (UTC)
Markup Renders as 
* example example example
* example example example
** this item has an extra 0.3em margin on top which the other list elements don't
** example example example
* example example example

  • example example example
  • example example example
    • this item has an extra 0.3em margin on top which the other list elements don't
    • example example example
  • example example example

– Thjarkur (talk) 17:02, 19 November 2019 (UTC)

@Thjarkur: Thans a lot for commenting! Yes, that does look much better. Is there any way the CSS settings could be generally fixed accordingly? Best wishes--Hildeoc (talk) 19:32, 20 November 2019 (UTC) @Thjarkur: Sorry for getting that wrong! Your example is just to illustrate the issue in question, right?--Hildeoc (talk) 20:20, 25 November 2019 (UTC)

@Hildeoc: I support the removal of the 0.3em top margin from lower level unordered lists. Þjarkur's proprosed rule should work. 

.mw-content-ltr ul ul {
   margin: 0 0 0 1.6em;
}

GUYWAN ( t · c ) 15:21, 26 November 2019 (UTC)

@Guywan: Thanks a lot for your interest! Now, does this require to be taken to Phabricator? If so, do you know anybody who knows his way around there, and who could do it?--Hildeoc (talk) 15:31, 26 November 2019 (UTC)
I would recommend posting this on Phabricator and then waiting rather than amending this css file. Vector is not the only affected skin (I see similar in Timeless today). --Izno (talk) 15:42, 26 November 2019 (UTC)
As this is the common css for all skins, I expect this is the right place to make a solution (I see the same problem in Monobook). Because we don't know what other margins might be in use now or in the future, it is best to make a correction using the most specific styling needed for the fix. In other words, only specify margin-top: 0;. Þjarkur's original suggestion is the right one. It should only be necessary to make an edit request here once consensus has formed. --RexxS (talk) 15:50, 26 November 2019 (UTC)
Ah, yes, you are correct, since the top margin is the only one we care about. GUYWAN ( t · c ) 16:40, 26 November 2019 (UTC)

Thanks everybody, so far! I just wanted to make sure one thing: I'd like this change to take effect globally, i. e. in all wikis. But would that be feasible at all?--Hildeoc (talk) 19:32, 27 November 2019 (UTC)

@Hildeoc: That can only be done by agreement of the developers or the 800 some-odd wikis. Usually the former is easier to get and the better place to request it anyway. Phabricator is the right place. --Izno (talk) 21:26, 27 November 2019 (UTC)
Agreed. If you want the change made for all wikis, Phabricator is the best place. --RexxS (talk) 21:33, 27 November 2019 (UTC)
@RexxS: Thanks. Do you know anybody with the necessary experience whom one could ask to take this to Phab then?--Hildeoc (talk) 13:33, 2 December 2019 (UTC)
@Hildeoc: You should try it out. :) See Help:Bug reports. --Izno (talk) 16:52, 2 December 2019 (UTC)
@Izno: Thanks for your confidence. However, I definitely don't have the capacity to learn the ropes of Phab …--Hildeoc (talk) 20:37, 4 December 2019 (UTC)
If you can figure out a MediaWiki wiki such as this one, Phabricator isn't hard. Filed as phab:T240113. --Izno (talk) 17:01, 8 December 2019 (UTC)

Hide book creator

Tracked in Phabricator
Task T241683

Per Wikipedia:Village_pump_(technical)/Archive_176#Suppress_rendering_of_Template:Wikipedia_books, please add the following code to Mediawiki:Common.css: 

#coll-create_a_book {
	display: none;
}

This will hide the "Create a book" link in the sidebar. --Yair rand (talk) 20:52, 31 December 2019 (UTC)

This should be an upstream change if we believe this no longer has value. --Izno (talk) 20:59, 31 December 2019 (UTC)
The English Wikipedia community came to a consensus that this link no longer has value. It should, therefore, do everything within its power to implement that consensus, including a change to the site styles if that is necessary. While I agree this would be less hacky if implemented upstream, I see no reason why that should stop this CSS change from being made. * Pppery * it has begun... 23:10, 31 December 2019 (UTC)
I'd say "everything within its power" could be going a bit too far in some cases. That said, the change requested here does not seem "too far" to me at this time, especially if we include a /* comment */ referring to a Phabricator task requesting this link be removed upstream. Anomie⚔ 15:02, 1 January 2020 (UTC)
Let's see a phab ticket for the removal - and make sure it doesn't go right to declined. — xaosflux Talk 15:13, 1 January 2020 (UTC)
Created phab:T241683. --Yair rand (talk) 16:10, 1 January 2020 (UTC)
@Yair rand: are you aware of any other need for: MediaWiki:Coll-add page, MediaWiki:Coll-bookscategory, MediaWiki:Coll-community book prefix, MediaWiki:Coll-intro text, and MediaWiki:Coll-savedbook template once this is removed? — xaosflux Talk 19:00, 1 January 2020 (UTC)
Someone could still go to Special:Book or the like. Anomie⚔ 03:14, 2 January 2020 (UTC)

Please implement the above change. * Pppery * it has begun... 20:03, 5 January 2020 (UTC)

 Done — xaosflux Talk 00:06, 6 January 2020 (UTC)

@Xaosflux: Hello, I just saw you added a celebration logo by CSS here. It is prboably better to do those changes via temporary logo change requested at Phabricator, because this way, clients are forced to download two logos instead of just one. --Martin Urbanec (talk) 11:35, 24 January 2020 (UTC)

@Martin Urbanec: I was going to go that route, but saw that phab:T117139 declined last time in favor of css so didn't bother. This should only be 2-3 days, and will be reverted. — xaosflux Talk 12:04, 24 January 2020 (UTC)
That's the wrong way around. It was declined because people jumped the gun and did it the wrong way here instead, even though this was rather foreseeable. :-) Jdforrester (WMF) (talk) 18:02, 24 January 2020 (UTC)
@Jdforrester (WMF): I agree in principal, but in practice it isn't always easy to get someone else to do something when you want it done - the nature of all volunteers and all! And getting staff to work on something like this would also need both sufficient advanced planning (which we certainly dropped the ball on here) but then also hoping that a staff will be available when you need one. I've been trying to get a response at User_talk:Jon_(WMF)#Temporary_Main_Page_Banner today for example but no reply yet - tried to engage volunteers on IRC about it too, lots of people in the support channel - fell on deaf ears. I'd like for a better issue and request intake and response system, but know that if you want things done in a timely fashion you need to dedicate money to having people available and I'm not the one to fix that! — xaosflux Talk 19:49, 24 January 2020 (UTC)

Interface-protected edit request on 26 January 2020

Has been up for 2 days ~14 hours, take it down in the next one-two hours or so?​ --qedk (t 桜 c) 09:33, 26 January 2020 (UTC)

 Done may take a little bit to clear from caches. — xaosflux Talk 14:01, 26 January 2020 (UTC)

Auto-hyphen

@TheDJ: adding an automatic hyphen was the worst thing ever I experienced with the Minerva skin, and I was wondering how it started and how to disable it! It must not be forcibly added to the skin without be given a choice to disable it. --Mahmudmasri (talk) 12:26, 23 March 2020 (UTC)

I dont have the rights anymore to change it. —TheDJ (talk • contribs) 12:38, 23 March 2020 (UTC)
It's discussed at Wikipedia:Village pump (technical)#Hyphenation on mobile view. Other users have complained. I support removal. PrimeHunter (talk) 13:29, 23 March 2020 (UTC)
Till then, I counteracted the script by adding a code to my Minerva CSS:

.content {
-ms-hyphens: none;
-webkit-hyphens:none;
hyphens: none;
}

--Mahmudmasri (talk) 20:09, 25 March 2020 (UTC)

 Fixed Jdlrobson (talk) 00:42, 26 March 2020 (UTC)

Add line for removing bold text from excerpts

When part of an article is transcluded into another using Template:Excerpt, there's usually a link from the transcluded article to the transcluding article, which ends up showing bold (since pages that link to themselves show bold). This can be seen for example at 2019–20 coronavirus pandemic#Misinformation. To fix this the following line would suffice: 

.excerpt .selflink {
    font-weight: normal;
}

Thanks! Sophivorus (talk) 09:37, 4 April 2020 (UTC)

 Not done @Sophivorus: I put this at Template:Excerpt/styles.css, and it appears to have resolved the use case you had. — xaosflux Talk 11:51, 4 April 2020 (UTC)
@Xaosflux: Wow! I was not aware of that feature, thanks! Sophivorus (talk) 12:43, 4 April 2020 (UTC)

Center

I wanted to see what the consensus was on adding a .center or div.center class, consisting of {width:auto; margin-left:auto; margin-right:auto;}. It would essentially be a more lightweight way of implementing {{center}}. The {{center}} template is used on half-a-million pages, and it often appears dozens or hundreds of times on a single page, so shortening its output to just <div class="center">...</div> would have a positive impact on page size and post-expand transclude size. It could also be used directly by other pages and templates that center elements without using the template. --Ahecht (TALK
PAGE) 14:22, 14 April 2020 (UTC)

You should consider using a WP:TSTYLE. --Redrose64 🌹 (talk) 14:46, 14 April 2020 (UTC)
@Redrose64: I certainly can in cases where a template calls {{center}}, but in cases where pages use the template directly a lot, adding the templatestyles tag to each invocation of the template would increase, not decrease, post-expand include size. A "center" class seems a lot more general purpose than thing like the navbox/navbar/ambox/tmbox/imbox/cmbox/ombox/fmbox/dmbox/infobox-specific classes that are included here. --Ahecht (TALK
PAGE) 16:21, 14 April 2020 (UTC)
Assuming that the stylesheet page Template:Center/styles.css gets created, the <templatestyles src="Center/styles.css" /> tag doesn't get placed in the page that uses {{center}}, it gets placed in the code of Template:Center itself. See for example Template:Quote which has <templatestyles src="Template:Quote/styles.css" /> right at the top; this therefore uses Template:Quote/styles.css. --Redrose64 🌹 (talk) 17:49, 14 April 2020 (UTC)
Which means that the tag is included every time the template is used. It does get deduplicated in the HTML output of the page, but still gets counted each time separately in the post-include expand size of the template. --Ahecht (TALK
PAGE) 17:57, 14 April 2020 (UTC)
This class already exists though. Try it:
Centered thing
It's defined in core somewhere, I think for use by thumbnails (I've seen at least one task to remove them).
I would be 100% against adding it here regardless. If you need something centered in a template, use TemplateStyles. If you don't, then either use {{center}} to center the thing or hand-do it on the page in question.
The box classes are slated for moving to TemplateStyles themselves, and Navbox/navbar/infoboxes are probably more a matter of time than of general regard for having them here, so don't use those as precedent (in fact, don't use precedent here :D). --Izno (talk) 16:53, 14 April 2020 (UTC)
@Izno: I think that centering is from mediawiki.skinning.interface (c.f. mw:Manual:Skinning_Part_2#Skin_styles_and_scripts_(Resource_Loader_modules)). — xaosflux Talk 18:20, 14 April 2020 (UTC)

/w/skins/Vector/images/bullet-icon.svg is not part of Mediawiki codebase

Unfortunately this CSS relies on it. Could someone replace or remove this part of the CSS? Kelson (talk) 16:47, 1 May 2020 (UTC)

@Kelson: removed as it doesn't exist - if there is something to replace this with that someone things we need, please request below. — xaosflux Talk 17:28, 1 May 2020 (UTC)
This is a familiar discussion. Please do more homework Kelson. The file is now at /w/skins/Vector/resources/skins.vector.styles/images/bullet-icon.svg . Xaosflux, if you would be so kind. --Izno (talk) 18:40, 1 May 2020 (UTC)
@Izno:  Done — xaosflux Talk 18:53, 1 May 2020 (UTC)

Interface-protected edit request on 11 May 2020

At the bottom of MediaWiki:Common.css, please remove 

/* Workaround pending completion of T241683*/
#coll-create_a_book {
	display: none;
}

Thanks to some work by myself and @Pppery, phab:T241683 has been resolved. Thanks, --DannyS712 (talk) 18:53, 11 May 2020 (UTC)

 Done Galobtter (pingó mió) 19:26, 11 May 2020 (UTC)

Interface-protected edit request on 17 April 2020

{{Collapsible list}} is used in numerous infoboxes but still uses the deprecated NavFrame system. There have been discussions about converting that template to use mw-collapsible, and User:TheDJ has been testing that in its sandbox for the past few years, but the most recent discussion last month has raised text alignment issues with the list title. There have also been complaints about whether it should be even used at all under MOS:DONTHIDE. In the meantime, I would still like a temporary hack so it is uncollapsed in the printed version. With my limited CSS knowledge, I believe something like this added on MediaWiki:Print.css could possibly fix it: 

ol.NavContent > li,
ul.NavContent > li {
	display: block !important;
}

I suppose that ol.NavContent and ul.NavContent could also be added to one of the other similar lines that uncollapse the other collapsible divs. Thanks. Zzyzx11 (talk) 04:16, 17 April 2020 (UTC)

Zzyzx11 The suggested change looks reasonable. Have you tested with your own personal CSS? Izno (talk) 22:49, 22 April 2020 (UTC)
Izno OK, I just tested it. Hmm ... I was only able to get it working in my CSS after I removed the greater-than signs:
ol.NavContent, ul.NavContent {
	display: block !important;
}
Good thing you have me test it. Maybe something else is overriding the greater-than signs. Thanks. Zzyzx11 (talk) 01:11, 23 April 2020 (UTC)
In a construct like 
ol.NavContent > li,
ul.NavContent > li { ... }
the part before the opening brace is a comma-separated list of selectors, and the > character is a child combinator. So the selector ol.NavContent > li represents a li element that is child of an ol element that itself belongs to the NavContent class. So if you remove the > li part you are moving the scope of the selector from the child element (li) to its parent (ol). --Redrose64 🌹 (talk) 13:09, 23 April 2020 (UTC)
OK, I looked at the code generated by {{Collapsible list}} and Module:Collapsible list again. The NavContent class is actually placed in the ul element. not in the li element. And there is no ol element. So this should be sufficient instead:
ul.NavContent {
	display: block !important;
}
Thanks. Zzyzx11 (talk) 03:25, 24 April 2020 (UTC)
A comma separates alternative selectors; it's like a logical OR operator. So what I wrote above concerning the ol element applies equally to a ul element. --Redrose64 🌹 (talk) 19:13, 24 April 2020 (UTC)
Well, apparently there is no ol element at all being used here. It is only the ul element that {{Collapsible list}} generates with the NavContent class. And none of the li elements are given any class or style that collapses. That is why I reduced it to what I did in my last suggestion after further inspecting what is being generated. And apparently the ul.NavContent element is being set to display: none by an already existing selector on MediaWiki:Common.css that is setting all the elements with the NavContent class (the selectors on MediaWiki:Common.css commented with "Reduce page jumps by hiding collapsed/dismissed content"). This is what I'm seeing going through something like the element inspector on Chrome. Zzyzx11 (talk) 07:47, 25 April 2020 (UTC)

@Izno, Zzyzx11, and Redrose64: is this change ready to go, because I notice the request has been open a month without action — Martin (MSGJ · talk) 11:12, 22 May 2020 (UTC)

I don't actually know. BTW this edit didn't notify me, so it won't have notified Izno and Zzyzx11 either. --Redrose64 🌹 (talk) 15:44, 22 May 2020 (UTC)
I didn't get the ping either, indeed, but I do watch the page. --Izno (talk) 16:02, 22 May 2020 (UTC)
Weird - I thought the ping would work if I resigned? — Martin (MSGJ · talk) 19:38, 23 May 2020 (UTC)
Unfortunately, it doesn't. The notification and the signature have to be made in the same post (otherwise you'd possibly trigger all sorts of unintentional notifications each time you signed a post). It's usually best to just to do a fresh post as an addendum containing the ping and the sig. --RexxS (talk) 19:48, 23 May 2020 (UTC)
I don't see any reason not to fulfill the edit request. --Izno (talk) 16:02, 22 May 2020 (UTC)
Go ahead. The last example with just the ul.NavContent element set to display: block !important; Zzyzx11 (talk) 05:41, 23 May 2020 (UTC)
 Done. Let me know of any problems please — Martin (MSGJ · talk) 19:38, 23 May 2020 (UTC)

Interface-protected edit request on 26 May 2020

Please add the following: 

#mw-indicator-move {
    float: left;
}

This will allow for correct display of Template:Move topicon (a proposed change to the move request notice being discussed here) to the left of other topicons when they are present (e.g. here). Courtesy pinging Wugapodes. {{u|Sdkb}} talk 05:18, 26 May 2020 (UTC)

@Sdkb: why can't you accomplish this with templatestyles? — xaosflux Talk 17:21, 26 May 2020 (UTC)
Even if we can't, I don't think it's appropriate to add CSS here for this case, which is rare enough that we shouldn't add it to the global stylesheet. --Izno (talk) 17:27, 26 May 2020 (UTC)
Indicators are not in mw-parser-output so templatestyles won't work. I agree with Izno. Galobtter (pingó mió) 19:33, 26 May 2020 (UTC)
.mw-parser-output can be added to wikitext, so it's possible that Template:Move topicon can be modified to emit the class and then TemplateStyles will function as expected (this is how Edit notices and a few of our Mediawiki interface overrides work). I don't know though and haven't tested this specific case. --Izno (talk) 20:08, 26 May 2020 (UTC)
Wugapodes is the one who coded this, not me, so they would be the one who could explain why they took this approach. {{u|Sdkb}} talk 20:35, 26 May 2020 (UTC)
I'm not very adept at template styles, so advice here is appreciated. I'll give Izno's suggestion a shot later today when I'm free. — Wug·a·po·des​ 22:52, 26 May 2020 (UTC)
@Izno: I tried this and it didn't work. According to mw:Extension:TemplateStyles#Caveats, the only way to target content outside the main parsed content is by wrapping the content in a div with the .mw-parser-output class. It seems the content we want to target must be inside those tags, but we cannot get #mw-indicator-move inside those tags. Looking at gerrit:162609 the indicator function is written so that the template takes no class attributes, and it is output separately from the rest of the wikitext so we cannot force it to be inside a wrapper div. Given the discussion here, I'll look into other solutions. — Wug·a·po·des​ 00:02, 28 May 2020 (UTC)
I read at gerrit:162609: Indicators are displayed ordered by their names (and not occurrence order). This ensures consistency across pages and provides a simple means of ordering or grouping them. Wouldn't changing the name of the indicator to something like |name=1move fix the ordering problems? Maybe "5-move" might be better as a case might arise in future where we want to put something to the left of the move indicator. --RexxS (talk) 16:58, 28 May 2020 (UTC)

check-icon

A brief look around seems to indicate that the check-icon CSS in common.css is basically unused. Outside of user space, there are a total of 7 uses. I don't think that is sufficient to be supported in Common.css and I think it should be removed accordingly. --Izno (talk) 15:49, 10 August 2020 (UTC)

I have a feeling this is no longer needed, as the way interwiki links are handled has evolved over the years, leaving open for feedback for a little bit. — xaosflux Talk 15:54, 10 August 2020 (UTC)
 Done revert if something blows up. — xaosflux Talk 13:35, 11 August 2020 (UTC)

CSS to left align the text in the first column of a table

Tracked in Phabricator
Task T2418

class=left-align-first-column

See discussion here: Wikipedia:Village pump (technical). The section currently titled: class="wikitable aligned linked" for linked country lists with flags (later note: archived here).

I have helped write Help:Table and Help:Sorting. I also write this page (and related pages) on the Commons: Commons:Convert tables and charts to wiki code or image files.

So I can say with confidence that this class will be used on thousands of tables.

There are many tables that use this below to align table data to the right side of table cells. It helps make data columns easy to scan, especially when sorted.

style=text-align:right;

But it causes country, state, and province lists to end up with the text for those countries, etc. aligned to the right side of those first-column cells. This class solves that problem in the easiest way.

The naming of the class I leave to others. I think dashes make the class name easier to read and understand by the most editors.

The CSS is here:

--Timeshifter (talk) 14:56, 12 August 2020 (UTC)

Timeshifter, we are trying to empty this file, we shouldn't be adding more to it. —TheDJ (talk • contribs) 18:51, 12 August 2020 (UTC)
"thousands of tables" might be true, but this page goes to many millions and millions of devices for each article, regardless of if the page has a table included or not, which is highly inefficient. This is exactly why we have template styles. —TheDJ (talk • contribs) 18:53, 12 August 2020 (UTC)
@TheDJ: Templatestyles is a pain to use compared to just adding class=left-column (or some other class name).
See the upper table at User:Timeshifter/Sandbox107. Imagine trying to get the average Wikipedia editor (who only occasionally edits tables) to remember to add this line to the table page:
<templatestyles src="Template:TemplateStyles sandbox/Jackmcbarn/aligned.css"/>
And if they forget to add it to the same article section as the table they will not see the left alignment in preview.
There are only 2 lines of CSS that would need to be added to Common.css to implement this class.
Surely there are 2 lines of CSS that could be removed from Common.css that are not being used, or only rarely used.
Maybe some day there could be separate CSS and JS pages just for tables. Somehow maybe they would only be imported to a browser when the Mediawiki software detects a table in a Wikipedia page.
--Timeshifter (talk) 13:01, 13 August 2020 (UTC)
@Timeshifter: You misunderstand how TemplateStyles are used. The invocation like <templatestyles src="TemplateStyles sandbox/Jackmcbarn/aligned.css"/> is placed inside the template itself, and is thereby transcluded into every article that uses the template. You don't need to put it any article. The addition of that tag is a job for the template designer, not for the article editor. --RexxS (talk) 23:30, 13 August 2020 (UTC)
@Timeshifter: In most of the tables that you describe, the first (text) column will almost always be a row header. We already have the class plainrowheaders which left-aligns those row-headers (which would otherwise be centred in most browsers). If the table is correctly marked-up and scoped, there are very few cases left where the class you are suggesting would have any use. --RexxS (talk) 19:28, 12 August 2020 (UTC)
I think adding this to common.css is overkill. I think the TemplateStyles-based approach we discussed on VPT would be better than this. Jackmcbarn (talk) 21:57, 12 August 2020 (UTC)

I replied at Wikipedia:Village pump (technical). --Timeshifter (talk) 01:19, 13 August 2020 (UTC)

Comment. Beside class=left-align-first-column we will need class=left-align-2nd-column - This is because often the first column in a table is a rank column. --Timeshifter (talk) 10:36, 14 August 2020 (UTC)

And class=left-align-3rd-column, presumably, if the first two columns are rank and date – and so on. None of these are needed if row headers are marked up according to MoS. If there's a sensible reason for not doing that, like daily updates using automated tools that don't supply proper markup, then WP:TemplateStyles can provide a solution. --RexxS (talk) 17:48, 14 August 2020 (UTC)
The first or second column is where the text needs to be aligned to the left for the vast majority of data tables on Wikipedia. There are no automated tools that add scope=row tags. And that automated tool would also have to change the cells in question to header cells if they are data cells currently. Because class=plainrowheaders only works with scope=row in rowheader cells.
In the meantime we need this class. You should ask for automated tools elsewhere. This is not the place for it.
WP:TemplateStyles is not meant for this. A commons.css class is much simpler. --Timeshifter (talk) 18:03, 14 August 2020 (UTC)
"There are no automated tools that add scope=row tags" Would you like me to write one for you? I know Magnus quite well, but we don't need to bother him for trivia. Magnus' code for tab2wiki is licensed as GNU GPL 3.0 and it only needs "\n!" changing to "\n!scope='col'|" in line 28 and "\n!" changing to "\n!scope='row'|" in line 35.
You don't need this class, and I can show you how to use TemplateStyles if you ever get around to explaining where you want to use your classes. --RexxS (talk) 22:37, 14 August 2020 (UTC)
RexsS. You obviously are clueless about tables if you don't know that there are tens of thousands of data tables that need their data cell text aligned right with text-align:right; added to the top of the wikitext. That means the left-most column needs text-align:left; or align=left added to all its cells. You'll catch on once you start paying attention instead of pounding your chest. Why are you talking to me instead of Magnus? Obviously because you are all talk. And if you can create the tool yourself more power to you. But stop wasting our time trying to hijack this thread. Until you actually DO something this class is needed. Using TemplateStyles is more complicated, as several people have explained. Using a common.css class is much easier. I am an admin/bureaucrat on a couple wikis outside Wikimedia. I am in charge of them. I know how easy it is to add stuff to Common.css, and how easy it is to use a class. Much simpler than TemplateStyles. --Timeshifter (talk) 02:23, 15 August 2020 (UTC)
See COVID-19 pandemic death rates by country for an example of how to do it. We don't need any more classes in common.css. Use templatestyles if you feel unable to use classes like "plainrowheaders". --RexxS (talk) 14:26, 15 August 2020 (UTC)
I've made a simple modified version of Magnus' tab2wiki that adds scopes at http://ivydene1.co.uk/demo/tab2wiki.php for you to have a look at. --RexxS (talk) 17:43, 15 August 2020 (UTC)
That's a start, but it is missing a few things that will prevent many people from using it. It needs the "Compress table" option found in the original tab2wiki. It makes tables easier to edit. The rowheader cells need a white background. Many people dislike row headers because of the black text on grey background. It is harder to read than black text on white background. From reading his user talk page I can tell that is what Aréat is complaining about at Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial. You and Justin show your unbelievable cluelessness ignorance about the visually impaired in the discussion on his talk page. A visually impaired person complains about black text on grey background. And then you and Justin say that MOS for the blind and visually impaired requires Wikipedia to ignore his complaint. So the plainrowheaders class needs its rowheader background color to be changed to white or light yellow or anything but grey. Until that happens we still need this new class. Because many people will not use this revised tab2wiki. Or they won't be using the rowheader part of it. And this tab2wiki may not help all tables. Some Wikipedia tables may not be able to be pasted into it, and converted to tables with scope=row. That will have to be seen over time. In the meantime we need this class. --Timeshifter (talk) 03:26, 16 August 2020 (UTC)
That language is totally inappropriate for Wikipedia (WP:NPA) and is particularly bizarre on this page where you are trying to get assistance from people with appropriate technical skills. Please focus on the issue and drop the emotion. Johnuniq (talk) 03:58, 16 August 2020 (UTC)
Johnuniq. Being against emotion is a gender-normative bias. It is one reason why Wikipedia has so few women editors and women admins. Your statement against emotion is against Wikipedia's current attempts by some editors and staff to recruit more women editors and admins. Please stop railing against emotion. It's unbecoming of an admin. I am an admin/bureaucrat on a couple wikis outside Wikimedia. People should be emotional when an editor so involved with MOS things related to the blind and the visually impaired is so (how shall I word this) totally unfeeling and uniquely without understanding concerning the complaints of Aréat. --Timeshifter (talk) 05:55, 16 August 2020 (UTC)
"Unbelievable cluelessness" is an exaggeration, and might be considered offensive. So I struck it out. --Timeshifter (talk) 18:36, 16 August 2020 (UTC)
Are...are you serious? You're trying to justify flying off the handle by appealing to a gender stereotype with nasty implications, and you're doing it in the name of gender equality. That is buckwild, and most certainly inappropriate. You really need to re-think your tone. Writ Keeper ⚇♔ 18:44, 16 August 2020 (UTC)
Tables don't need to be "compact", and using horizontal syntax leads to errors when using attributes like style and scope. It is easiest for editors to learn to edit tables in their vertical syntax because that doesn't generate the errors, which merely cause confusion.
Black text on the wikitable header background exceeds WCAG 2.0 AAA standards by a large margin; see https://snook.ca/technical/colour_contrast/colour.html#fg=000000,bg=EAECF0. Not only is that combination used in all wikitable column headers, which you don't seem to have a problem with, but it is inconceivable that any person who can read black text on a white background cannot read the same black text on the grey background used.
I've worked on accessibility issues on Wikipedia for over ten years now, and I object to your rude mischaracterisation of me. Please now remove all of your personal attacks from this page. The decision to keep the header background colour for row headers was made in November 2010 at MediaWiki talk:Common.css/Archive 12 #Bold row headers (Solution 3 in particular), where you can see my contributions to the creation of the class. If you wish to change this long-standing consensus on the background colour of row headers, you are free to make your arguments. But nothing that you have brought froward so far seems to have any more strength than those found in WP:IDONTLIKEIT. --RexxS (talk) 21:03, 16 August 2020 (UTC)
I've strongly criticised editors who don't seem to care about accessibility issues before, as it's something that does anger me greatly. But I don't see any evidence anyone here does not care about accessibility. More to the point, from what I've read and understood, it seems to me that Timeshifter's proposal is missing the forest from the trees when it comes to accessibility issues if there is a genuine problem cause by the use of the scope tag and row headers with light grey background and black text. Providing another option so that some editors can ignore the guidelines and avoid the use of scope tags and row headers does not solve the accessibility problem. If there is a problem, we need to resolve it for all tables as far as possible and update our guidelines so editors do not continue to harm accessibility when they are following the guidelines for accessibility. In case there is still confusion, my point is I don't see how we are helping the visually impaired by telling them 'if you're lucky, someone who is aware of Timeshifter's CSS solution may use it, ignoring the accessibility guidelines and potentially harming screen readers in the process. Meanwhile everyone else especially most of our tables especially those create by editors care about accessibility are going to continue to create tables which are hard for you to read because they are following the guidelines and want to ensure there is no risk to screen readers, tough cookies on that front. ' That's why I think RexxS's question on the MOS talk page makes sense. We need to investigate the issue and try and work out why Aréat is having a problem with a colour combination that is supposed to be okay according to the guidelines developed outside wikipedia by people who are supposed to be experts on such things. Especially since whatever they said on their talk page before, their comment on the MOS talk page ("the black text with a dark grey font") doesn't seem to describe the situation (there's a light grey background but no dark grey font). Nil Einne (talk) 09:08, 17 August 2020 (UTC)
@Nil Einne:. From looking at his user page I think Aréat may be a native speaker of French. So that may explain the confusion with some of his messages. On Aréat's talk page though he is more clear:
I've read it, and seen nothing indicating the left column must be centered, bolded on dark grey background. It make it less easier to read in the first place. This is absurd. ...

Look at the table you're proposing and honestly tell me it's easier to read a text that is black on dark grey? This [MOS] is obviously wrote by people who don't use it. You can't make it less easier to read on a whim. ...

I have a very poor vision and I reverted the changes you made to a table that made it way more difficult to read, and that isn't used anywhere on the election pages I've been participating on for years, where the tables have been fine to read. I reverted the pages to the version they were before you went there, imposed your changes and kept reverting despite being asked to go to the talk page.

--Timeshifter (talk) 19:43, 17 August 2020 (UTC)
Black text on a background of #EAECF0 is not an accessibility issue according to both WCAG (where it meets their AAA standard) and WP:COLOR. Not only that but I explained to Aréat that they could make a white background for themselves by adding a line to their own css:

In your case, you could add something like 

th { background-color:#FFF }

to your personal user stylesheet to provide a white background for you.

Aréat is more active on French Wikipedia, but has made 6,500 edits to English Wikipedia since 2010 and has a talk page replete with warnings for edit-warring. If they are having difficulty understanding WP:DTT, I could ask my colleague, Dodoïste who wrote the tutorial to explain to them in French. Although, the French Wikipedia has exactly the same background colour in its table headers as does English, so I would have thought they were familiar enough with the combination from their home wiki. --RexxS (talk) 21:29, 17 August 2020 (UTC)
  • Comment. I now think that classes would be a far easier way to add scope=row and scope=col to all headers. For simple tables without colspan and rowspan there should be something like
class=left-aligned-scope that would add scope=row and scope=col to all headers, and align the text in row headers to the left. --Timeshifter (talk) 05:55, 16 August 2020 (UTC)
  • Comment 2. There should be other classes to convert all first column (or 2nd column) cells from data cells to header cells:
1st-column-headers
2nd-column-headers --Timeshifter (talk) 05:55, 16 August 2020 (UTC)
  • Comment 3. There should be other classes for row header cells that makes their background color white, yellow, light yellow, or other light colors other than grey:
white-rowheaders
yellow-rowheaders --Timeshifter (talk) 05:55, 16 August 2020 (UTC)
  • Comment 4. class=scope could combine them all (except color) for simple tables without rowheaders or scope. Colors:
white-scope
yellow-scope
--Timeshifter (talk) 06:00, 16 August 2020 (UTC)
  • class=wikitable - It could be expanded to add scopes to all header cells, including those spanning columns and rows (colspan and rowspan). And it could align row header text to the left as does class=plainrowheaders. And the wikitable class could add a yellow or light yellow background to headers. That would solve Aréat's visual impairment problem with dark grey as a header background. It would help all readers. Highlighter felt-tip markers usually come in some shade of yellow. That is because this background color behind black text is one of the most legible color combinations. Many people do not like bolded row headers. Especially in country lists, and other tables, where the width matters due to long country names, etc.. That is a good thing about plainrowheaders in that it does not use bolded text in row headers. There is no reason all of this could not be incorporated into class=wikitable. For more examples, info, and tables see: User:Timeshifter/Sandbox114. This table below has all scopes (scope=row, scope=rowgroup, scope=col, scope=colgroup). Plus class=plainrowheaders. I made one cell light yellow to show a couple shades of yellow. Check the wikitext to see how cluttered it is.
Correctional supervision rates by state, 2016.




Jurisdiction 		Total Community supervision Incarcerated
Total,
12/31/2016 		Rate per
100,000
adults 		Probation
or Parole,
12/31/2016 		Rate per
100,000
adults 		In prison
or jail,
12/31/2016 		Rate per
100,000
adults
 Alabama 99,800 2,640 60,700 1,610 40,900 1,080
 Alaska 12,900 2,320 8,400 1,520 4,400 800
 Arizona 137,500 2,570 84,800 1,590 55,000 1,030

Wikitext for above table if class=wikitable did scopes and color. It's much simpler to edit by the average editor. Compressed format is more intuitive without all the scopes and color styling. 

{|class="wikitable sortable mw-datatable" style=text-align:right;
|+ Correctional supervision rates by state, 2016.
|- 
! rowspan=2 |<br><br><br><br>Jurisdiction
! colspan=2 |Total 
! colspan=2 |Community supervision 
! colspan=2 |Incarcerated
|-
! Total,<br>12/31/2016 
! Rate per<br>100,000<br>adults 
! Probation<br>or Parole,<br>12/31/2016 
! Rate per<br>100,000<br>adults 
! In prison<br>or jail,<br>12/31/2016 
! Rate per<br>100,000<br>adults
|-
! {{flaglist|Alabama}} 
|| 99,800 || 2,640 || 60,700 || 1,610 || 40,900 || 1,080
|-
! {{flaglist|Alaska}} 
|| 12,900 || 2,320 || 8,400 || 1,520 || 4,400 || 800
|-
! {{flaglist|Arizona}} 
|| 137,500 || 2,570 || 84,800 || 1,590 || 55,000 || 1,030
|}

--Timeshifter (talk) 23:28, 17 August 2020 (UTC)

There is related discussion here:
--Timeshifter (talk) 06:12, 29 August 2020 (UTC)

Class for vertically aligned table rows

Hello. Can you please consider adding a table class to make vertically aligned wikitable (<tbody>) rows? It seems tedious and repetitive to keep on adding style="vertical-align:top;" on each table row that needs vertical alignment. Frietjes mentioned to me that class "infobox" has "vertical-align:top;" table rows, though it adds more styles than just vertical alignment which conflict with the "wikitable" class styles. Thank you.–Sanglahi86 (talk) 16:57, 15 September 2020 (UTC)

Previous discussion. This is not really appropriate for Common.css. --Izno (talk) 19:25, 15 September 2020 (UTC)

listify CSS

The .listify CSS isn't doing anything. I've documented some findings on Template:Transcluded table as list, but in case that template should be deleted at some point in the future (maybe as a result of this discussion -- I am happy to G7 it):

Transclusions of special pages like in <ul class="listify">{{Special:PrefixIndex/Template:Transcluded table as list}}</ul> used to output a table. This CSS allowed those tables to be (roughly) styled as lists instead. Most commonly, the class is used in XFDs to display previous XFDs (amusingly incorrect in its use of the <ul> element rather than a <div>). The originating discussion was in 2007.

However, this CSS is no longer necessary for that use case as the transclusion now correctly outputs a list directly rather than a table. Consequently, the transformation the CSS applies is no longer needed. Currently:

Extended content
<div class="mw-prefixindex-body">
<ul class="mw-prefixindex-list">
<li><a href="..." title="...">...</a></li>
...
</ul>
</div>

I suggest this search is representative of potential uses (no lookaheads in search regex means I can't be 100% certain...); I verified none of them are a use case which is not the above, which means there is 0 use for the class.

Its use as some kind of selector in user CSS is limited to [exact copies of Common.css rather than as e.g. .listify {display: none}. Accordingly, please remove the following: 

/* Allow transcluded pages to display in lists rather than a table. */
.listify td {
	display: list-item;
}
.listify tr {
	display: block;
}
.listify table {
	display: block;
}

Meanwhile, I will go hunt for existing templates dumping this class into wikitext. :) --Izno (talk) 04:31, 11 November 2020 (UTC)

All removed. --Izno (talk) 06:22, 11 November 2020 (UTC)
 Done — xaosflux Talk 18:25, 11 November 2020 (UTC)

Fixing the accidental return of decorative quotations

Tracked in Phabricator
Task T265947

Please see also: Wikipedia talk:Manual of Style#Fixing the accidental return of decorative quotations
 — SMcCandlish ☏ ¢ 😼  01:37, 12 November 2020 (UTC)

I was able to hide the unwanted border with blockquote {border-style: hidden !important;}. There may be a more elegant way, and I haven't tested for undesirable side effects. – Jonesey95 (talk) 16:56, 17 November 2020 (UTC)
Insufficient specificity. .mw-body-content blockquote { border-left: none; } to match the rule causing the grief at .mw-body-content blockquote { border-left: 4px solid #eaecf0; }. Possibly .mw-body-content blockquote { border-left-style: none; } may be necessary. .mw-body-content blockquote { border-left: 0; } might also work to force the width to nil. Could also set the color to transparent. Any of the above should work. --Izno (talk) 17:28, 17 November 2020 (UTC)
To be most obvious of course, 'none' should be preferred. --Izno (talk) 17:31, 17 November 2020 (UTC)
@SMcCandlish: is this only occurring in Vector? (Such that a hack against it can be limited to MediaWiki:Vector.css) — xaosflux Talk 17:33, 17 November 2020 (UTC)
Hmm, looks like Minerva has it too. — xaosflux Talk 17:38, 17 November 2020 (UTC)
It's been in Minerva for some time; that's why it's in the style guide to begin with. The use case on Minerva is more defensible, since on mobile resolutions we don't want to waste N ems worth of whitespace for block quotations. On Vector, there's no reason for it. --Izno (talk) 17:43, 17 November 2020 (UTC)
I don't see it in Monobook or Timeless either, so probably just Vector. Also, Izno's .mw-body-content blockquote { border-left-style: none; } works for me in my vector.css. Can someone put it in MediaWiki:Vector.css, please? – Jonesey95 (talk) 18:20, 17 November 2020 (UTC)
queued an edit request, pending some additional testing. — xaosflux Talk 18:56, 17 November 2020 (UTC)
Oh, I probably should have said something, but .mw-body-content blockquote { border-left: none; } fixed it for me. I was just hoping it could be my first act of rebellion against the WMF addition in support of the community as an interface admin later today. ;) --Izno (talk) 18:59, 17 November 2020 (UTC)
 On hold @Izno: probably should give this a LITTLE time for any other discussion below to take place first, but you can "reserve" it :D I added intadmin to you on testwiki (testwiki:User:Izno) if you want to start pre-testing this against an actual Vector.css file first (please be sure to undo any tests you create on pages like that at testwiki when you are not actively testing them). — xaosflux Talk 20:07, 17 November 2020 (UTC)
Yes, unexpected resistance. :^) --Izno (talk) 20:10, 17 November 2020 (UTC)
@Izno: did you get a chance to verify the fix on testwiki? — xaosflux Talk 03:50, 19 November 2020 (UTC)
Blockquote and Vector.css. Works peachily. --Izno (talk) 15:17, 19 November 2020 (UTC)
@Izno: barring any serious objections below, seems like this is ready to go then. — xaosflux Talk 17:54, 19 November 2020 (UTC)

May I ask where decorative quotations got banned? I'd be curious to read the discussion that led to it, as I personally quite like the new styling (and I wouldn't really say that a single vertical line is "decorative", unlike e.g. the quote marks on {{cquote}}). Matma Rex talk 19:58, 17 November 2020 (UTC)

Matma Rex, may I ask where decorative vertical lines were discussed? :) --Izno (talk) 20:07, 17 November 2020 (UTC)
To that end, I honestly can't see it as anything but decorative. It serves no obvious function and moreover obscures the function that the indent does serve, which is to indicate a block quote as taught and understood in the majority of the English world. The decorative quotation 'ban' was the one that took out curly quotation marks, but it might be reasonable on your part to argue that didn't apply to vertical lines. Given the response so far, I don't think it would be much a stretch to say there would be support for removing it, the same as the earlier quote marks were removed. --Izno (talk) 20:10, 17 November 2020 (UTC)
(On that note, I have been reminded again that {{talk quote block}} does something similar to the border here.) --Izno (talk) 20:16, 17 November 2020 (UTC)
@Izno I don't think the vertical lines were discussed anywhere, or at least not anywhere that is documented, it was just an arbitrary decision. But I got the impression from the discussion here that not having any markers around blockquotes was a policy here on en.wp, and not an arbitrary decision, and I was just curious why. I'm not going to argue with you on this, I just wanted to know the context. Matma Rex talk 16:45, 18 November 2020 (UTC)
@SMcCandlish: I see this is in the MOS, Wikipedia:Manual_of_Style#Block_quotations can you point to where any of the RfC's you mentioned about it are? — xaosflux Talk 20:11, 17 November 2020 (UTC)
I don't know about RFCs, but the stuff about not using decorative quotation marks has been in there for a while. I expect that it is based on long-standing guidance from style guides like MLA and APA. Both of those recommend simple indentation of the block quotation (although they also have other guidance that is more specific than we could probably get consensus for here on en.WP). – Jonesey95 (talk) 22:30, 17 November 2020 (UTC)
I can dig it up, but I'm running out of steam for the day. The most recent major discussion of this was at WT:MOS within the last year or so. It'll be pretty easy to fish it out of the archives there. PS: I am not yet certain exactly what skins, etc., this change is affecting. Others probably already have looked into that more than I have. I wasn't aware that this had WP:TALKFORKed into an edit-request already. :-)  — SMcCandlish ☏ ¢ 😼  01:14, 18 November 2020 (UTC)
We're usually pretty swift about maintaining status-quo when unexpected software pushes change reader-facing content. — xaosflux Talk 03:52, 18 November 2020 (UTC)
Alright... I mean even if you like the new style -- even if you like it lot -- the developers have no right to do this. I therefore oppose it on principle. My opinion on the merits doesn't matter -- and neither does yours, or anyone elses. That's the way the Wikipedia works and has to work. Herostratus (talk) 14:46, 21 November 2020 (UTC)

As to discussions, there have been very many over the last decade-plus, some well attended and some being formal RfCs. (I'm talking about {{Cquote}}/{{Rquote}} here although the other quote templates were discussed some. {{Cquote}}/{{Rquote}} were made, with large pastel quotation marks, about 15 years ago or so. Shortly thereafter some random person wrote an admonition to not use them in articles (in any useful manner) into the documentation. A lot of editors ignored the documentation and used them anyway. And that's how matters stood for 10+ years.)

Anyway there were many discussion to change this, with various options described. The pastel-line-on-the-side thing got some love, but nowhere near a majority in any case. The nothing-at-all option got a a fair amount of love. The large-pastel-quotemarks got a fair amount of love -- never a majority, but there was also a fair amount of "well very many editors have voted with their feet to use them, so let them do so" type thinking, so they by status-quo stayed in for a good while. (An admonition not use them, in the documentation, in the MOS, was snuck in underhandedly over 10+ years ago and then used in a "well people need to follow the rules, is all" argument. FWIW. But that's ancient history.)

Anyway, eventually there was another RfC, about one or two years ago, offering a binary choice of "keep the large pastel quote marks" or "don't, and have nothing instead". "Don't, and have nothing instead" was clear consensus in a reasonably well-attended RfC. "Thick pastel line on the side" was not on the table, but as I said above that never got near enough love in any to be considered a consensus choice or even close.

That's the basic summary, if you want take some hours to read through the discussion over the last 10-12 years, a compact list of the links exists somewhere. But I forge where. You could dig them up, or just take my word for it.

Anyway -- I opposed the removal of the large pastel quote marks, quite vigorously and at length. I still think I'm right. But I'll enforce the consensus decision -- no decorative elements at all. Unless and until there's a new consensus. That's how we have to roll here. And some computer programmers with extra time on their hands dorking around does not constitute a consensus. Herostratus (talk) 14:46, 21 November 2020 (UTC)

The links I'd meant to get around to digging up are: Of most perfect relevance, this TfD, the deletion (not merger) of a template that did exactly what the recent dev changes did: put a left-side vertical bar as a border on block quotations. Next is this recent RfC that ended the giant-quote-marks stuff in mainspace (I don't know if it's been extended in later discussions to doing the same with other "décor-quotes" templates, though I think that would be the ultimate result). That followed on this proposal, on decorative pull quotes and templates for them in articles, generally (and there was at least one before that, along similar lines). Herostratus has frequently complained that because the templates were also often [mis]used for non-pull-quote, regular ol' block quotations (despite MOS:BQ saying to use only {{quote}} or raw <blockquote>...</blockquote> markup, that this decision-making is somehow invalid. It is not. The concerns have always been exactly the same: using attention-grabbing decoration to give WP:UNDUE, magazine-style emphasis to a particular quoted statement. It has jack to do with the editor's reasoning for doing it, with the speaker/writer of the quote, or with exactly which method of decoration the template employs. The reasoning is not invalidated by MoS later effectively banning pull-quotes except in unusual cases, and then (after 2 more RfCs) considering them just completely encyclopedically inappropriate at all. Since the main concern was always the UNDUE issue, repurposing the templates for block-quote decoration was never just a-okay.

On the ranty-pants matter: A provision surviving for over a decade in one of the most watchlisted WP:P&G pages on the entire system isn't "sneaking" anything "underhandedly" (and attack language like this is why MoS got put under WP:AC/DS). It's normal editing and consensus formation. Not every line in every page requires an RfC, and long survival of guideline provisions is prima facie evidence of consensus for them (though of course it may change). Probably at least 90% of our P&G material was simply edited in, without prior formal discussions, which are mostly a later development, because our P&G are well-developed and willy-nilly changes to them now have a destabilizing effect. (Remember also that before the 2010s, RfCs were mostly used for what their name suggests, gathering opinions; not as basically a voting system). But we've had our RfCs anyway, and MOS:BQ and these template have been discussed over and over and over again, so it is literally impossible that something just ended up in MOS:BQ without support. And if its advice did not have consensus, {{Quote}} would not do what it does, but do something else, something fancified.

I really have no idea why Herostratus has been advancing this demand for decorated block quotations in mainspace, so hard and for so long. A lengthy if not permanent rest needs to be given to it. Especially since the reaction to what the devs did has produced consternation (including from editors with no idea what the cause was, i.e. with no argument to make about procedural appropriateness, only about the appearance), without any competing chorus of thanks and joy. At some point it needs to sink in that WP is not going to be styled like a ca. 2005 blog. (That said, the overall WP look-and-feel is probably over-ripe for another refresh. Just not "bar-quotes", which have already been losing favor in the medium they arose in. I just looked at a bunch of online tutorials for styling block quotations and pull quotes in various blog packages, and they are remarkably devoid of "bar quotes", a style which seems to have become passé in the early 2010s.)
 — SMcCandlish ☏ ¢ 😼  00:38, 1 December 2020 (UTC)

Never mind; I found the answer to where Herostratus is coming from on this, stated unequivocally way back in 2011: "I don't like this. The blockquote templates are ugly. The cquote templates are pretty. ... [D]on't make me use [Template:Quote] when there's something available that I think looks better." – emphasis in original. So, it's pure WP:ILIKEIT. Well, commingled with WP:ICANTHEARYOU: it also says, "I mean if there's a good reason to not use the cquote templates for regular quotes, that's different. But I haven't seen one put forward. ... My inclination is to run an RfC changing the MOS (and template documentations) to allow the editor to use cquote-type templates for regular quotes if they want to. [B]ut before I do that, is there anything I'm missing here?" Yes, clearly, almost a decade later.  — SMcCandlish ☏ ¢ 😼  10:31, 1 December 2020 (UTC)
  • @Izno: ready to do this, if not I will (barring objections). — xaosflux Talk 16:16, 21 November 2020 (UTC)
     Done No objections since and a half dozen editors in favor of removal. There may come a time when we should use a media query to limit the removal (when new Vector becomes responsive) per the display in Minerva, but we can sort that down the road (along with everything else we might care about w.r.t. a responsive Vector). Izno (talk) 18:58, 21 November 2020 (UTC)
    Thank you. Is this going to handle the rest of the desktop skin? Some thoughts: If a style like this is effectively necessary on the mobile version because traditional block-quotation indents don't work in those space constraints, we can probably live with that. However, it would probably be better to actually reformat them as "regular double-quote-mark quotations, like this", just long ones. Would certainly be a more seamless mobile reading experience, and the bar takes up horizontal room it need not, just less than that absorbed by indented blocks.  — SMcCandlish ☏ ¢ 😼  00:38, 1 December 2020 (UTC)
    If/when the styles show up in another skin, we can consider moving to Common.css or copying the fix to that skin's CSS.
    regular double-quote-mark quotations, like this That would look weird without also making it inline with the previous paragraph, and there's no guarantee it will have been formulated with an inline appearance in mind (consider that most of our inline quotations have the footnote come after, not before as with most of our basic-blockquotes). (Never mind the subsequent need for templates like {{quote}} to also have to consider it for their trailing elements.) The bar is probably about as good as we can get not least because I do think some portion of the web via Medium or Wordpress or even Gmail recognize a left bar as indicating a quotation. A box (as with {{quote box}}) wouldn't do it save where other information was provided to make it obvious. --Izno (talk) 04:33, 1 December 2020 (UTC)

Interface-protected edit request on 26 November 2020

.dropbtn {
  background-color: #4CAF50;
  color: white;
  padding: 16px;
  font-size: 16px;
  border: none;
}

.dropdown {
  position: relative;
  display: inline-block;
}

.dropdown-content {
  display: none;
  position: absolute;
  background-color: #f1f1f1;
  min-width: 160px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  z-index: 1;
}

.dropdown-content a {
  color: black;
  padding: 12px 16px;
  text-decoration: none;
  display: block;
}

.dropdown-content a:hover {background-color: #ddd;}

.dropdown:hover .dropdown-content {display: block;}

.dropdown:hover .dropbtn {background-color: #3e8e41;}

Ginoozzo (talk) 14:48, 26 November 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit interface-protected}} template. And a reason. Izno (talk) 15:06, 26 November 2020 (UTC)

Removing user-block

Resolved

I have moved the styles for user-block inline to the various templates that use them since they were a mix of substed and unsubsted templates (rather than TemplateStyles).

I think it might be wise not to remove the CSS from this sheet today because that will cause a lot of unstyled block notices that may be interesting in the immediate future. If we remove it a little later (some weeks, maybe the end of December?), then I suspect that switchover will be less noticeable.

There's nothing to be done about the 1 million+ blocked uses. A bot would be necessary but that seems like a lot of unnecessary edits to me.

I have also sorted the related user CSS (why do so many people copy-paste Common/monobook/vector.css and/or the developer copies of the same)? There are several remaining references, some of which are false positives. The true positives in that set will have to decide how they want to (re-)implement the styles for their person (!important where necessary ofc.).

Any issues with that approach? --Izno (talk) 19:35, 28 November 2020 (UTC)

@Izno: can you give some examples of pages that will become unstyled (i.e. pages that used subst'd templates that are hard-coded to a style here) - having a bot "fix" them if it isn't an important change isn't likely needed. — xaosflux Talk 20:25, 28 November 2020 (UTC)
@Xaosflux: 700k+ user talk pages (times out, so there's probably more). --Izno (talk) 20:39, 28 November 2020 (UTC)
@Izno: OK so the result will be something like seen here: User:Xaosflux/sandbox91 right? Having a bot put ~1MM colored boxes seems like overkill? — xaosflux Talk 23:34, 28 November 2020 (UTC)
Xaosflux, yeah, that was my opinion. My worry was that editors and blocked persons would miss unstyled block notices, which I think should be okay after some time of leaving inline-styled notices. --Izno (talk) 00:09, 29 November 2020 (UTC)
This should probably get a wider discussion first, QEDK do you know if there is a wikiproject that coordinated all of those templates? — xaosflux Talk 00:50, 29 November 2020 (UTC)
I found evidence to that effect while working through uses at Wikipedia:WikiProject User warnings (they covered user block templates too apparently). --Izno (talk) 03:57, 29 November 2020 (UTC)

Interface-protected edit request on 15 December 2020

Following up from this VPT thread, could we add a class to show content to only non-extended confirmed users, similar to what we have for unconfirmed users at MediaWiki:Group-autoconfirmed.css? Thanks, {{u|Sdkb}} talk 19:54, 15 December 2020 (UTC)

Another use case for this just came up here (look at Praxidicae's !vote). {{u|Sdkb}} talk 23:14, 22 December 2020 (UTC)
@Izno: Following up from Discord, I tried testwiki, but I don't have the permissions to edit MediaWiki:Group-extendedconfirmed.css, so I don't think I can do any sandboxing. As I mentioned there/above, the code should be pretty much the same as what we have for the autoconfirmed page, so: 
.nonextendedconfirmed-show {
  display: none !important;
}
Cheers, {{u|Sdkb}} talk 21:20, 29 December 2020 (UTC)
@Sdkb: "only non-extended confirmed users" - so for example bots and admins? — xaosflux Talk 23:06, 29 December 2020 (UTC)
Xaosflux, heh, well, since admins and bots can edit extended confirmed pages (and presumably see things in the extendedconfirmed-show class?), I'd think we'd want to exclude them from the nonextendedconfirmed-show class. Whatever is included in extendedconfirmed-show, this should be the inverse of that. {{u|Sdkb}} talk 23:15, 29 December 2020 (UTC)
@Sdkb: just to be clear, you want us to make a new class, nonextendedconfirmed-show that has display:none, but only make that class available to people that are extended confirmed (when you apply that class to things it will normally do nothing, unless you are ec; at which point it will display:none it). So long as this is never used for "content" should be fine I guess. — xaosflux Talk 01:37, 30 December 2020 (UTC)
 Done — xaosflux Talk 01:38, 30 December 2020 (UTC)
Xaosflux, thanks! And sent you an email. {{u|Sdkb}} talk 01:59, 30 December 2020 (UTC)
I can't help feeling worried about this, see this discussion from almost fifteen years ago. Graham87 and RexxS, please check. --Redrose64 🌹 (talk) 16:06, 30 December 2020 (UTC)
From a purely screen-reader-using point of view, it'll be fine these days ... all modern screen readers in use support CSS properly. Also it won't be used very widely ... I don't ever anticipate it would be used at somewhere like {{main}}, like HiddenStructure was. Graham87 16:58, 30 December 2020 (UTC)

Infoboxes?

I use the timeless skin, and infoboxes appear to be coming at 100% width. Can somebody fix this? Eshaan011 (talk) 22:15, 7 January 2021 (UTC)

The issue is tracked at phab:T271473 and affects most tables. The issue is caused by some Javascript, so it would be hard to override from CSS. We could try some !important in Timeless.css, but otherwise, you might consider using a different skin if you are finding it impossible to use right now. --Izno (talk) 22:25, 7 January 2021 (U

plainrowheaders on mobile

Is it possible to enable the special display of plainrowheaders on mobile? In Common.css, it is implemented on lines 438–442: 

.wikitable.plainrowheaders th[scope=row] {
	font-weight: normal;
	/* @noflip */
	text-align: left;
}

— Goszei (talk) 00:43, 13 February 2021 (UTC)

 Done --Izno (talk) 22:40, 17 February 2021 (UTC)

Dark mode

(I'm sorry if I missed a previous discussion, but I could not find anything for "dark mode" and related search terms.)

Would you consider adding styles for a dark mode? See https://en.wikipedia.org/wiki/Light-on-dark_color_scheme for details.

Reasoning

From a UX perspective, many people prefer it over the default mode (e.g. https://medium.com/dev-channel/let-there-be-darkness-maybe-9facd9c3023d). Widespread browser add-ons like https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph/details or apps like https://nighteye.app use Wikipedia to illustrate their purpose, indicating demand for it. And the potential reduction of energy consumption alone might justify adding such a feature.

Possible approach

A very basic implementation like the following could be used to gather initial user feedback: 

@media (prefers-color-scheme: dark) {
  /* Invert colors */
  html {
    filter: invert(1);
  }

  /* Revert images */
  img {
    filter: invert(1);
  }
}

This would only apply the inverted styles to users showing their intent to use a dark mode.

Assuming a positive response, specific, more fine-tuned styles could be added instead. — Preceding unsigned comment added by 85.195.250.26 (talk • contribs) 16:39, 5 February 2021 (UTC)

Dark mode is hard. We have frequent requests for it, usually in other forums (WP:VPT, CommTech EOY survey, and at least one task on Phab). There is a gadget for users who log in. Otherwise, I do not think we should take on the effort of maintaining any sort of dark mode implementation here. We will get complaints from the readers where some content inverts color but not all of it (and there will be a lot of that, as demonstrated by the size of the dark mode scripts I've seen). Opting into either the gadget or one of the browser extensions seems preferable to me. --Izno (talk) 22:56, 6 February 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css/Archive_18&oldid=1092618884"