MediaWiki talk:Common.css

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

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 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 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

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

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:

• Template:TemplateStyles sandbox/Jackmcbarn/aligned.css

--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:

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 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)