Template talk:Div col

From WikiProjectMed
Jump to navigation Jump to search

Rules parameter adds extra line to end

The rules parameter incorrectly places a vertical line after the last column, given the columns aren't as wide as the window. You can see this effect with one to two items, or with a wider window, three to four items. The vertical line should be placed between existing columns, not to the right of them.

  • Item 1
  • Item 2

Jroberson108 (talk) 23:50, 9 November 2020 (UTC)[reply]

I have added a test case. It looks fine to me in Firefox for Mac (two columns with a rule in between). In Safari for Mac, I see a blank, ruled column between items 1 and 2, with a rule following item 2. In Chrome, I see two columns with a rule in between, then a rule to the right of the second column. So it looks correct in only one out of three browsers for me. – Jonesey95 (talk) 00:08, 10 November 2020 (UTC)[reply]
On Windows 7, it looks fine in Firefox, but has the extra line in Chrome. On Android phone, it looks fine in both Firefox and Chrome. Jroberson108 (talk) 00:43, 10 November 2020 (UTC)[reply]
Izno, while you are messing about with this template, do you have any interest in troubleshooting this one? – Jonesey95 (talk) 06:00, 5 January 2021 (UTC)[reply]
Displays with 2 rules in Chromium Edge for Windows 10 and Chrome for Android for me (Chrome is up to date but my phone OS is old.) This is probably an upstream task for Chromium rendering. I don't see a task in the relevant Chromium bug project.
Displays correctly in both Firefox Quantum and Firefox Daylight.
Fun stuff, neither line displays for me on the mobile website for either Chrome or Firefox. Does MobileFrontend just not care about any Tstyles? :) This style seems fairly benign... --Izno (talk) 06:15, 5 January 2021 (UTC)[reply]
Now filed at 1163025. --Izno (talk) 06:33, 5 January 2021 (UTC)[reply]
Bug was confirmed. I added a bit about it being an issue for N columns and N-1 rules as well as the basic 2 and 1 case. --Izno (talk) 04:48, 8 January 2021 (UTC)[reply]
  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5
  • Item 6

@Izno: I added a fix for this on the sandbox styles. There are other styles that add a margin-bottom to the "li" elements that cause the extra line to show. You can check it and add it to the live styles. Jroberson108 (talk) 13:13, 9 February 2022 (UTC)[reply]

I think it's prudent simply to wait for Chrome to fix their software. Izno (talk) 18:09, 9 February 2022 (UTC)[reply]
@Izno: Issue doesn't seem limited to just Chrome. Extra line on Windows (Chrome, Edge) and Mac (Chrome, Safari). Correct on Firefox for Windows and Mac. Mobile version is correct on Windows (Chrome, Edge, Firefox). From Edge's user agent containing "Chrome", Edge might be fixed if Chrome fixes it? Not sure about Safari? Jroberson108 (talk) 17:20, 19 February 2022 (UTC)[reply]
Yes, Edge uses Chromium as its rendering agent since a year or three ago. Safari being broken is a Safari problem at this point, the browser is known to be subpar from a standards perspective at this point. Izno (talk) 17:31, 19 February 2022 (UTC)[reply]
This appears to have been fixed. The bug was closed resolved and I confirm that Edge displays correctly now. Izno (talk) 20:42, 5 July 2022 (UTC)[reply]

Add option to disable break-inside: avoid-column;

The current no column break behavior is actively harmful for those who need multilevel lists. The CSS should either be removed completely (since it is redundant with a {{no col break}} template), be hidden behind a switch (as a class), or at least a class should be added to allow for restoring it to the original. An example to play with is at https://jsbin.com/hufotaq/edit.

The first option is trivial. I think it makes the most sense, but it can be quite intrusive; some weighing is required.

The second option requires the addition of a parameter to the template. Simply change the first line of the template to have <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}} {{#ifeq:{{{nobreak|}}}|yes|div-col-nb}}" instead of <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}}". After that, replace .div-col li, .div-col dd with .div-col-nb li, div-col-nb dd, where div-col-nb is the name of the new class. (It also causes immediate global change, but a nobreak can be easily applied to all elements for unpleasant-looking lists.)

The third, least intrusive, option also requires the addition of a parameter. Change the first line of the template to have <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}} {{#ifeq:{{{allowbreak|}}}|yes|div-col-brk}}" instead of <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}}". After that, add the following to the CSS:

/* Allow break between columns */
.div-col.div-col-brk li, /* Over-specifying is required to up the importance */
.div-col.div-col-brk dd {
	page-break-inside: inherit;
	break-inside: inherit;
}

(We sadly cannot make a template called {{yes col break}}. The avoid-column directive on the enclosing element takes precedence.)

--Artoria2e5 🌉 15:09, 4 January 2021 (UTC)[reply]

@Artoria2e5: Based on my review while working on removing Template:Columns, the general case is not a multilevel list, so I would not support removing this from the default appearance. That's ignoring the fact that this has been in this template's CSS since Forever (via the column class prior to my update).
Overspecifying in your CSS is not generally necessary as the last applicable CSS applies. I don't imagine this would be "first".
We sadly cannot make a template called {{yes col break}}. This is not strictly true; if we were interested we could make this more meta-templatey and add some sort of |child templatestyles= or |between templatestyles= (or something of the latter) which would allow you to insert another template/templatestyles page (probably the former for this template) between the templatestyles tag and the opening div.
Can you put something in a personal sandbox so we can see the behavior at issue? This bit of the CSS is not something I'm familiar with and MDN can be a little lackluster with its examples at times. --Izno (talk) 03:58, 5 January 2021 (UTC)[reply]
Izno, I put the thing into the normal Template sandbox. See Template:Div_col/testcases#allow_break for how it looks. (It will work a lot better with a rule, I will say that.)
PS. The main article use I have right now is ATP-binding_cassette_transporter#Cross-species_subfamilies.--Artoria2e5 🌉 09:49, 5 January 2021 (UTC)[reply]
Okay, so I added a few others to the sandbox. Browsers (Firefox at least) will cut content into smaller columns even if there are sublists, if it thinks things are unbalanced enough. "column-avoid" is exactly how it works today-- it's a suggestion, not a requirement for the browser. --Izno (talk) 01:28, 27 January 2021 (UTC)[reply]
 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Elliot321 (talk | contribs) 07:07, 21 January 2021 (UTC)[reply]

From Wikipedia talk:Vector 2022

Please look at this discussion. Patafisik (WMF) (talk) 16:05, 3 February 2023 (UTC)[reply]

Odd bug in 5-column layout

Five columns w/ 12 elements renders with 2/3/3/3/1 elements in each column. At narrower and wider widths (4 and 6) it renders properly. – SJ + 18:21, 3 March 2023 (UTC)[reply]

The bug, at colwidth=10em and 5 columns
The bug, at colwidth=10em and 5 columns
Your header says 5, but the text says four. It's working fine for me (expand or contract your window to get four columns; I get four columns of three items at my default screen width). If I zoom my window, it jumps from 4 columns to 6 columns (of two items each), skipping 5 columns entirely. Please link to a page where this is happening, and let us know what skin you are using (in Preferences - Appearance) and what web browser. – Jonesey95 (talk) 19:09, 3 March 2023 (UTC)[reply]
@Sj: Regardless of the number of columns, the number of items per column is browser dependent and outside our control. Indeed, there is nothing in the CSS Multi-column Layout Module Level 1 specification to indicate where such control may be specified. Even when the total number of items divides exactly by the number of columns, you cannot be certain that each column will have the same number of items - if one item is longer than the column width, forcing a wrap, this may cause that column to be slightly longer, or it may cause one item to be pushed into an adjacent column. So twelve items in a five-column layout may be split 2/3/3/3/1, or 3/3/2/2/2, or 2/3/2/3/2 (etc.). We just don't know. --Redrose64 🌹 (talk) 23:32, 3 March 2023 (UTC)[reply]
Thanks for all the detail, both of you. See if you get the same effect on the source page: d:Wikidata:WikiProject_source_reliability#Wikipedia_Perennial_Lists
(Perhaps one of those lines is secretly very long? You can see they all look like two-letter codes. I haven't seen it in any other configurations.) – SJ + 00:15, 4 March 2023 (UTC)[reply]
Over on that Wikidata page, using Vector 2010 and Firefox for Mac OS, as I expand my page, I get 6/6, 4/4/4, 3/3/3/3, 2/3/3/3/1, 3/3/3/3 again, 2/3/3/3/1, and then 2/2/2/2/2/2. Going from four columns to five, then back to four again, as I make the window a little wider is completely baffling to me. – Jonesey95 (talk) 05:50, 4 March 2023 (UTC)[reply]
Like I said, five into twelve won't go - it's 2 remainder 2, and we cannot predict where those odd two will end up, nor whether items are moved from the top of one column to the bottom of the previous, or vice versa. Without carefully examining the browser's source code in order to analyse its algorithm, all we can say is that if all the items are the same length, the browser won't try to put more than three items into any one column.
By means of the break properties (see CSS Fragmentation Module Level 3) it is possible to instruct the browser to keep two items together in the same column, or to force a column break between two particular items or even inside an item that is known to be very long. But this is only useful if the number of columns is fixed - when a column width is specified and the user's display characteristics are unknown (as here) you don't know how many columns there will be, and definitely shouldn't attempt to manipulate column breaks artificially. --Redrose64 🌹 (talk) 12:09, 4 March 2023 (UTC)[reply]

plainlist fails

Template:Div col#TemplateData gives plainlist as an example class but it has no effect after plainlist was removed from MediaWiki:Common.css in [1]. I think plainlist should work in |class= or possibly a separate parameter like |plainlist=yes. I used {{div col}}{{plainlist}}...{{endplainlist}}{{div col end}} in an article [2] but that's ugly and hard to figure out. PrimeHunter (talk) 15:30, 29 March 2023 (UTC)[reply]

I know much less than I should about CSS, but I think I may have fixed it. I then made this edit to the article in question, and it appears to have preserved the formatting. YMMV, since I am a whacker when it comes to CSS. – Jonesey95 (talk) 18:15, 29 March 2023 (UTC)[reply]
If you're going to wrap things, you should wrap them the opposite way so that the columns CSS is correctly applied.
But yes, that is the appropriate way to do things going forward. Izno (talk) 18:23, 7 November 2023 (UTC)[reply]
Just wondering though, would it be better to add <templatestyles src="Plainlist/styles.css"/> to Template:Div col rather than adding the css to Template:Div col/styles.css? -- WOSlinker (talk) 21:41, 7 November 2023 (UTC)[reply]
Neither. If you want a div col to have a plain list, wrap the div col with plainlist. Izno (talk) 21:53, 7 November 2023 (UTC)[reply]