Template talk:Reflist

Latest comment: 3 months ago by Peshigome in topic Default Height

Update default width to 25 em?

edit

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

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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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 html 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)Reply
(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)Reply
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)Reply
Ah, i don't know how the tag is implemented -- does reflist inherit default width from it? – SJ + 15:18, 21 September 2023 (UTC)Reply
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)Reply
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)Reply
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)Reply

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

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

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

Making empty reflists useful

edit

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

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

The 'talkpage' parameter?

edit

Hi, I have noticed {{reflist|talkpage}} at Talk:Conway base 13 function (specifically, here: Special:permalink/1212662718#Almost everything maps to 0?). It seems to do similar thing to {{reflist-talk}} but without the 'References' title and a bordering frame. Could someone, please, describe the talkpage parameter at the template's doc page? --CiaPan (talk) 08:41, 3 July 2024 (UTC)Reply

The first positional parameter controls column width. Since talkpage is not a number specifying number or width of columns, {{reflist}} simply ignores talkpage and renders as it would in a mainspace article. Probably a typo.
Trappist the monk (talk) 10:31, 3 July 2024 (UTC)Reply
OK, so I inserted {{reflist-talk}} there. --CiaPan (talk) 13:12, 4 July 2024 (UTC)Reply

Default Height

edit

Hello, I come from the French Wikipedia.

On our Wikipedia, when references are numerous, we use a Références nombreuses template (numerous references) which has the particularity, which your Reflist has not, to be adjustable in height, with 30em as the default.

You can see this in action on our Kate Bush page, which has as many (if not more) references as your Kate Bush page, but thanks to the maximum height of the references, it has better ergonomics.

For this to happen, I noticed that our reference list has an additional div around the ol element, and of course some additional CSS.

I think it could be interesting to add this to your Wikipedia as well.

Peshigome :3 (Blah Blah | Contributions) 08:43, 29 August 2024 (UTC)Reply

Our manual of style says not to use such scrolling lists due to concerns over accessibility. Anomie 10:44, 29 August 2024 (UTC)Reply
Ho okay, yeah ok, Scrolling list explicitly ask not to use scrolling list on reference lists. — Peshigome :3 (Blah Blah | Contributions) 10:39, 30 August 2024 (UTC)Reply