The redirect Template:RefIist has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 September 13 § Template:RefIist until a consensus is reached. SWinxy (talk) 05:17, 13 September 2023 (UTC)

The new aggressively-wide side margins in the default skin (Vector 2022) mean that on most monitors at 100% zoom reflist always renders as single column This is one of my greatest frustrations with the skin, and I don't think I'm alone (as @CJDOS: noted above) :).

While we continue to push for less enthusiastic sidebar width and padding, the default reflist column width could also be revised so that refs are two columns in some "standard browser size" configuration. Say a 1200px wide window, running the default skin, with sidebars open? I believe 25em would work. – SJ + 13:18, 19 September 2023 (UTC)

I'd rather see us fix Vector 2022 locally with CSS than change this reflist default that has worked well for many years. I can easily get two reflist columns on my 13-inch laptop screen in Vector 2022 with CSS that fixes the absurd whitespace, leaving me with 69em of space for content (it is 94em in Vector 2010 on the same screen). – Jonesey95 (talk) 14:12, 19 September 2023 (UTC)

I agree. It should be V22's job not to break things that have worked for years, not our job to work around their changes. RoySmith (talk) 14:44, 19 September 2023 (UTC)

This "I don't like the defaults so I'm going to prevent anyone else from making them more usable" approach is...not constructive. —David Eppstein (talk) 15:10, 19 September 2023 (UTC)

Let me rephrase. I have no problems with this being fixed in the V22 CSS loaded by enwiki, but as somebody who doesn't use V22, I don't want to see changes to the template which will affect what I see to accomodate V22. RoySmith (talk) 15:21, 19 September 2023 (UTC)

Maybe there is some magical CSS way to make the default 23 or 25 em for Vector 2022 and keep it at 30 em for Vector 2010. – Jonesey95 (talk) 15:38, 19 September 2023 (UTC)

I'll ask in Phab, (update: asked in T347109) this is reasonably specific and may get a response there. – SJ + 15:18, 21 September 2023 (UTC)

You can use different values for vector and Vector 2022.

To target styles based on skins, use a selector such as body.skin-vector-legacy .myClass; specification of the body element is required and must be followed by a descendant combinator (i.e. the space). Other classes on the body or doc elements may be targeted in the same manner. See phab:T197617. 1.32+

(mw:Extension:TemplateStyles#Usage)

feature queries can also be used in modern browsers. Jdlrobson (talk) 18:29, 27 September 2023 (UTC)

(ec)If we want to make this change, we would presumably also want it implemented in <references /> since there are plenty of articles with <references /> instead of {{reflist}} as the default widths are the same at the moment. Mike Christie (talk - contribs - library) 14:15, 19 September 2023 (UTC)

Yeah I think this would be the better way. I'm someone who uses the <references /> tag instead of {{reflist}} in my articles. SWinxy (talk) 15:02, 20 September 2023 (UTC)

Ah, i don't know how the tag is implemented -- does reflist inherit default width from it? – SJ + 15:18, 21 September 2023 (UTC)

Reflist inherits the width from the CSS of the skin being used, which is 30em in Vector 2010. When a value is put into the template, then it overrides the skin to make the width something else. SWinxy (talk) 18:23, 21 September 2023 (UTC)

Hmm, if that is true, why do we have Template:Reflist/styles.css? Did you mean to say that <references /> inherits the width from the skin's CSS? – Jonesey95 (talk) 21:47, 21 September 2023 (UTC)

JK I was wrong. It's not set in the skin, the default column width seems to actually be pulled from the Cite extension: ext.cite.styles.css. The templatestyles does the whole list-style-type thing, and .reflist-columns-2/.reflist-columns-2 are for backwards-compatibility, but the rest don't seem to need to be there. SWinxy (talk) 23:43, 21 September 2023 (UTC)

Phab ticket about this, please comment there: T347109 – SJ + 02:18, 22 September 2023 (UTC)

I use Vector 2022 with the sidebar, and I get two columns of references on both my PC and iPad. Out of curiosity I tried switching the iPad to portrait mode, and got a single column of references. Switching the ToC to the top menu with the Vector 2022 "hide" button gave me two references even in portrait mode. This strikes me as a more natural answer than changing global css. Is there some reason why those with monitors too narrow for two columns of references would not want to set Vector 2022 to have the ToC hidden in the top button? Mike Christie (talk - contribs - library) 12:02, 22 September 2023 (UTC)

I assume you're leaving the toolbar menu closed as well?

Logged out users get the TOC expanded by default, which is convenient. And they won't know that there's an option for references to be two columns. The question for them is whether they are likely to be using a persistent Tools toolbar. Logged-in users are more likely to want to access the tools regularly as well.

The experience varies a lot with combinations of window size and default font size. Many readers use windows between 1200 px and 1680 px with font zoom between 100% and 133%. Here are a few width break points for when refs become two-column (Mac/FF):

• main/toc open, tools hidden: 1100 | 1210 | 1310 | 1420 px: 100|110|120|133% zoom
• main/toc and tools open: 1350 | 1500 | 1620 | >1680 px : 100|110|120|133% zoom

The body column has become a second-class citizen, and is the only one whose width is variable, so sidebars that feel normal at a 1800px-wide window at 100% zoom are quite big at 1280px. As a result, what feels like a significant range of normal use cases have body columns that fall between 50em and 60em in width, hence this request.

This is in addition to, not as a replacement for, requests to reduce sidebar margins and horizontal whitespace across the board, including the "bonus" 60px margin that gets added to the main menu at a window width of 1200px / 100%. – SJ + 19:57, 23 September 2023 (UTC)

 You are invited to join the discussion at Help talk:Footnotes § List-defined references in the Visual Editor. Rjjⁱⁱⁱ(talk) 03:45, 22 September 2023 (UTC) If list-defined references work in Visual Editor only without this template, then it probably should not be used to create them. Rjjⁱⁱⁱ(talk) 03:45, 22 September 2023 (UTC)

Would it be feasible to display a message—probably something similar to {{no footnotes}}—when a page has a {{Reflist}} template but no footnotes defined? This was briefly discussed at Wikipedia_talk:WikiProject_Unreferenced_articles#Empty references sections? (@Boleyn and Broc:) and I think also recently at one of the village pumps. – Joe (talk) 08:40, 21 April 2024 (UTC)

The text would have to be different to {{no footnotes}} because there would be no way of telling if there is a list of references, related reading, or external links. Given that the only information you have is that that no footnotes are properly defined (there could even be an attempt at inline references, not using a <ref> tag), I think the most it could say would be something like:

This article doesn't appear to have any footnotes.

It could also create an appropriate maintenance category, which would either be useful or worrying depending on the amount of previously unknown unsourced articles it reveals. -- D'n'B-t -- 09:33, 21 April 2024 (UTC)

That looks good, yeah. Also a good idea with a tracking category. My major question is whether it's possible to detect the lack of <ref> tags within the template. – Joe (talk) 09:35, 21 April 2024 (UTC)