This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 15 | Archive 16 | Archive 17 | Archive 18 | Archive 19 |
see: Wikipedia:Village pump (technical)/Archive_160#Mirror of template:Tree list/final_branch
It was suggested that I ask here:
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)
#wpSave
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
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)
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)
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)
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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
.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)
currently, the {{
gallery}} template generates borders around the images, but the <gallery>...</gallery>
tag does not.
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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
Can the top navigation bar please have a position: fixed;
added?
Nixinova
T
C
01:57, 20 July 2018 (UTC)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
@ 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'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)
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)
/* 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;
}
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)/* Content in columns with CSS instead of tables (
Template:Columns) */
section. —
xaosflux
Talk
00:00, 28 July 2018 (UTC)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)
Errors you make here can disrupt the entire encyclopedia, "so make sure you know what you are doing. Always check with the W3C CSS Validation Service before and after any changes.". Thank you, Otr500 ( talk) 18:08, 12 August 2018 (UTC)
(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:
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)
|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)
{{[ ]*[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)
<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)
|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)This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
This
edit request to
MediaWiki:Mobile.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
[[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)This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
<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;
}
<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:
And with gallerybox 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)
<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:@ 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)
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)
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)
.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)
.ns-0 .gallerybox .thumb img,
.ns-2 .gallerybox .thumb img,
.ns-100 .gallerybox .thumb img,
.nochecker .gallerybox .thumb img {
background-image: none;
}
This
edit request to
MediaWiki:Common.css and
MediaWiki:Group-extendedconfirmed.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please add to common.css, under .patroller-show,, above .autoconfirmed-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; }
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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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 ahref$=".pdf".external,
div#content ahref*=".pdf?".external,
div#content ahref*=".pdf#".external,
div#content ahref$=".PDF".external,
div#content ahref*=".PDF?".external,
div#content ahref*=".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)
/* Change the external link icon to an Adobe icon for all PDF files */
.mw-parser-output ahref$=".pdf".external,
.mw-parser-output ahref*=".pdf?".external,
.mw-parser-output ahref*=".pdf#".external,
.mw-parser-output ahref$=".PDF".external,
.mw-parser-output ahref*=".PDF?".external,
.mw-parser-output ahref*=".PDF#".external,
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please remove the following block:
div#mw_content ahref$=".pdf".external,
div#mw_content ahref*=".pdf?".external,
div#mw_content ahref*=".pdf#".external,
div#mw_content ahref$=".PDF".external,
div#mw_content ahref*=".PDF?".external,
div#mw_content ahref*=".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)
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)
.hatnote {
font-style: italic;
}
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)
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)
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)
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)
This
edit request to
MediaWiki:Group-checkuser.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
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)
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)
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)
.mw-contributions-list .flaggedrevs-unreviewed,
.mw-contributions-list .flaggedrevs-color-1 {
background-color: inherit !important;
}
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)
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)
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)
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)
.myTemplate .hlist...
and then your changes only impact the template of interest. --
Izno (
talk)
14:50, 12 July 2019 (UTC)<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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
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)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? Ladsgroup overleg 19:21, 15 July 2019 (UTC)
<div class = "mw-parser-output">
Let's keep a centralized progress checklist. — TheDJ ( talk • contribs) 22:06, 23 July 2019 (UTC)
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)
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)
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)
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)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
@ The wub: I've applied the change. Please let me know of any issues — Martin ( MSGJ · talk) 20:48, 29 November 2019 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
.navbar ul {
display: inline;
white-space: nowrap;
}
.navbar ul {
display: inline-block;
white-space: nowrap;
}
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)
Any comments?-- Hildeoc ( talk) 16:26, 19 November 2019 (UTC)
.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 |
|
– Thjarkur (talk) 17:02, 19 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)
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)
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)
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)
/* comment */
referring to a Phabricator task requesting this link be removed upstream.
Anomie
⚔
15:02, 1 January 2020 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please implement the above change. * Pppery * it has begun... 20:03, 5 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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
@ 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)
.content {
-ms-hyphens: none;
-webkit-hyphens:none;
hyphens: none;
}
Fixed Jdlrobson ( talk) 00:42, 26 March 2020 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
<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)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Unfortunately this CSS relies on it. Could someone replace or remove this part of the CSS? Kelson ( talk) 16:47, 1 May 2020 (UTC)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This
edit request to
MediaWiki:Print.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
{{
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)
ol.NavContent, ul.NavContent {
display: block !important;
}
ol.NavContent > li,
ul.NavContent > li { ... }
>
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)
{{
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;
}
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)
ul.NavContent
element set to display: block !important;
Zzyzx11 (
talk)
05:41, 23 May 2020 (UTC)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
mw-parser-output
so templatestyles won't work. I agree with Izno.
Galobtter (
pingó mió)
19:33, 26 May 2020 (UTC)
.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)
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)This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
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)
class=left-column
(or some other class name).<templatestyles src="Template:TemplateStyles sandbox/Jackmcbarn/aligned.css"/>
<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)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 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)
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)
"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.
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. |
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)In your case, you could add something like
th { background-color:#FFF }to your personal user stylesheet to provide a white background for you.
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)1st-column-headers
2nd-column-headers
--
Timeshifter (
talk)
05:55, 16 August 2020 (UTC)white-rowheaders
yellow-rowheaders
--
Timeshifter (
talk)
05:55, 16 August 2020 (UTC)class=scope
could combine them all (except color) for simple tables without rowheaders or scope. Colors:white-scope
yellow-scope
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.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)
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)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This
edit request to
Mediawiki:Vector.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please see also:
Wikipedia talk:Manual of Style#Fixing the accidental return of decorative quotations
—
SMcCandlish
☏
¢ 😼
01:37, 12 November 2020 (UTC)
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)
.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)
.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).mw-body-content blockquote { border-left: none; }
fixed it for me. I was just hoping it could be my first 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)
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)
{{
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)
"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)
regular double-quote-mark quotations, like thisThat 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)
This
edit request to
MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
.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)
{{
edit interface-protected}}
template. And a reason.
Izno (
talk)
15:06, 26 November 2020 (UTC)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)
This
edit request to
MediaWiki:Group-extendedconfirmed.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
.nonextendedconfirmed-show {
display: none !important;
}
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)
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)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)
!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 (UIs it possible to enable the special display of plainrowheaders
on mobile? In Common.css, it is implemented on lines 438–442:
.wikitable.plainrowheaders thscope=row {
font-weight: normal;
/* @noflip */
text-align: left;
}
— Goszei ( talk) 00:43, 13 February 2021 (UTC)
(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 /info/en/?search=Light-on-dark_color_scheme for details.
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.
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)